Privacy Policy — GobernIA

Versión en español: Política de privacidad

Version: 1.0
Effective date: November 6, 2026

1. Who we are

GobernIA is a product of Prodeo Innovation (website: https://prodeoinnovation.com).

• Full legal name: Prodeo Innovation S.A.
• Address: Escazú Village, Guachipelín, Escazú, San José, Costa Rica
• Jurisdiction and governing law: Costa Rica
• Privacy contact: info@prodeoinnovation.com

2. What GobernIA is

GobernIA is an Atlassian Forge app for Jira Service Management Cloud. It installs and verifies, on the customer’s own site, the scaffolding for governing AI agents defined by the AIGOV methodology: fields, screens, statuses, workflows, a project and an Assets schema. It diagnoses the site, builds a plan, simulates it without writing and, after a deliberate confirmation, applies the steps it can execute (it writes to the site); every operation is recorded. The app approves nothing: people make the decisions. It is meant for site administrators and lives on an administration page inside Jira; in production, applying requires the Administer Jira permission (section 4).

This policy describes how the app is designed to work. It is informational and does not create any warranty or obligation beyond those set out in the End User Terms.

3. Where it runs and where data goes

• GobernIA runs on the Forge platform: compute and storage are Atlassian’s.
• The app’s manifest declares no external destination (there is no permissions.external). The code has no network calls of its own: every call goes through Forge’s functions to the Jira, Jira Service Management and Assets of the same site, plus the app’s report to Atlassian’s own personal data reporting API (section 8).
• The app does not send data to Prodeo or to any third party. There is no telemetry, analytics or remote Prodeo service.
• The data the app stores is in the Forge storage (KVS) of your installation. Atlassian operates that storage; its encryption, per-installation isolation and residency are Atlassian’s and are governed by Atlassian’s documents, not by a promise of ours. Data residency follows the location the administrator chooses in the host Atlassian product.

4. What site data the app touches

To read and write on the site the app acts with its own identity (not that of the person operating it). One call is different: when someone opens the Apply dialog or presses Apply in a production installation, the app asks Jira, with that person’s own identity, whether their account holds the global Administer Jira permission (GET /rest/api/3/mypermissions?permissions=ADMINISTER). That call reads only the permission of the person asking, and the answer is used to allow or deny: nothing from it is stored except the outcome the audit log records (an authorization or a refusal, under the person’s alias). The app asks nobody for Atlassian tokens, passwords or credentials.

It reads, in order to compare with the model: the site’s configuration catalog — names and identifiers of custom fields and their options, screens, schemes, statuses, workflows, issue types, the designated project, request types, and the model’s Assets schema (object types, attributes, reference types, objects), plus the list of global icons of the site’s Assets workspace (identifier and name), because Assets requires an icon for each object type.

It writes, when a person applies a plan: only after that person simulated and reviewed it and confirmed in a dialog; only elements whose exact name the model declares; and, in a production installation, only if Jira confirms the person holds the Administer Jira permission. The run re-reads the site first and is refused if it no longer matches the plan that was reviewed. It never deletes anything from your site and there is no automatic undo (the code has no delete call; retiring something is a state). In this release it creates custom fields with their contexts and options, screens, an issue type, the Assets schema and reference types and, when an icon has been resolved on your site, Assets object types, attributes and objects. It does not create statuses, workflows, the project, request types or AQL filters: those steps are issued as specifications to complete by hand, with the reason on screen, and are never reported as done.

The Assets icon is chosen per site and per customer. Assets cannot receive an icon from the app, so the app looks on your site for the icon whose name its parameters declare and, if there is none or several, an administrator picks one from the site’s own list in the console. The choice is saved for that installation only (section 5).

Scopes. The manifest declares 24 scopes, in two groups. 23 are used by a line of the app’s code today: reading Jira work and the configuration catalog (also used for the administrator check above), managing Jira configuration and the designated project, Jira Service Management request types, the Assets schema, types, attributes, objects and icons (read:cmdb-icon:jira), the app’s own storage, and Atlassian’s personal data reporting API (report:personal-data). 1 is declared ahead of the feature that will use it, and the code does not use it yet: read:jira-user (planned change-approval features: deriving approvers and comparing requester against approver). Four other scopes that were declared ahead of time are now in use: write:jira-work and write:servicedesk-request for change approvals, and read:confluence-content.all and write:confluence-content for the daily witness of the conformity seal in Confluence. A committed scope is declared ahead of time because adding a permission after the first installation forces a new major version and each administrator’s consent; it is removed from the manifest if the feature it is for does not ship. Today the app writes to Jira issues and reads and writes one Confluence page; it does not read user profiles, and the permission screen an administrator sees nevertheless includes Jira write, Jira user read and Confluence content. read:jira-work is a broad Atlassian scope that technically allows reading issues, but today the app does not read issues, comments or user profiles. When a feature that reads user profiles ships, this policy is updated before that version is released (reading people means handling personal data: the account id and what the Jira user API returns).

The names of configuration objects are whatever the customer gave them. If the customer typed personal data into a field, screen or workflow name, the app may read it for the plan; it does not look for it or separate it out.

5. What data the app stores

All of it in the installation’s Forge KVS:

What	Content	Identifiable person
Audit log (append-only, hash-chained)	Every operation and every refusal: time (UTC and Costa Rica time), environment, site identifier (cloudId), verb and target of the operation, digests of what was sent and a redacted summary of up to 2,048 bytes (a parameter of the app), result, app version, model fingerprint, run identifier	Pseudonymous: an opaque alias of whoever operated, not their accountId (see Person register)
Run state	Stage reached, steps executed, evidence per step; while a run is in progress, the steps of its plan (model element, action, endpoint, digests of the site’s state, reason texts); the site URL and the licence state of the installation	Pseudonymous: the alias of whoever launched it
Run lock	Who took the execution turn, when, and its expiry	Pseudonymous: the alias of whoever launched the run
Production authorization	A single-use authorization record tied to one plan: alias of whoever authorized, site and installation identifiers, plan fingerprint, expiry and a proof computed with the installation key	Pseudonymous: the alias of whoever authorized
Chosen Assets icon	The identifier and name of the icon an administrator picked for this installation, the date, and the alias of who picked it	Pseudonymous: the alias of whoever picked it
Person register	One record per person who operated the console: their Atlassian accountId, the alias assigned to them, the creation date and the date from which the data is current. It is the only place the accountId is kept	Yes: the accountId
Conformity seal	Result per criterion and its signature	No
Id map	Which Jira or Assets identifier corresponds to which model element	No
Seal signing key	32 random bytes generated by the app, kept in Forge’s secret store	No
Installation authorization key	32 random bytes generated by the app on first use, one per installation, kept in Forge’s secret store; it signs the single-use authorizations. Nobody types it or sees it	No

What is not stored: anyone’s real name, email, photo or phone number (the app holds no display name, only the alias and, in the person register, the accountId); any customer credential. There is no production key to store: the authorization is the Administer Jira permission, checked against Jira, plus the installation key above, which the app generates and nobody types. An automated test checks that the accountId appears in exactly one stored record and in no stored value.

About the accountId and the alias. The accountId is the Atlassian account identifier and the alias is a random identifier the app assigns to each person. While the person register holds the record, the app can resolve an alias to its accountId (the console does it so the administrator sees who operated), so audit log entries are entries of an identifiable person. We treat the accountId, and the alias while it can be resolved, as personal data. What they are kept for: recording who operated, who authorized and who chose the icon (audit of the customer’s own governance) and preventing two simultaneous runs. We use them for no other purpose. Legal basis for the processing: the Customer’s legitimate interest in auditing its own governance and the performance of the licence agreement with the Customer; where the applicable law requires a different basis (for example consent), obtaining it is the Customer’s responsibility as controller.

Roles. Our position is that the customer decides why it records those operations (its own audit) and that GobernIA processes them on the customer’s behalf. The Customer is the controller of this data. Prodeo has no access to it in the normal operation of the app, because it stays in the Forge storage of the Customer’s installation; to the extent Prodeo processes any of it (for example in a support case), it does so as a processor and only on the Customer’s instructions. Customers that need a data processing agreement (DPA) can request one at info@prodeoinnovation.com; its terms are agreed case by case.

6. Who it is shared with

• Third parties from the app: none. The app shares no data with sub-processors.
• Atlassian hosts the app and its storage and processes data under its own terms and privacy policy. This policy does not replace them.
• Providers Prodeo uses for its support correspondence (section 10): Microsoft (Microsoft 365 email service, United States and other Microsoft data centres), used only to receive and answer support and privacy correspondence.

7. How long it is kept

• While the app is installed. The app deletes nothing by design (retiring an element is a state, not a deletion), with one exception: it deletes a person’s record from the person register when Atlassian reports that account as closed (section 8). It has no automatic expiry: everything else written to the KVS stays until the app updates it, and the app does not delete it.
• After uninstall, the lifecycle of Forge hosted storage applies, which Atlassian manages. We state no period of our own because Atlassian’s official documentation is not uniform on the exact number of days; see its current documentation (https://developer.atlassian.com/platform/forge/storage-reference/hosted-storage-data-lifecycle/).

8. Access, correction and deletion

What the app does when an account is closed.

• The audit log, the run state, the run lock, the production authorizations and the chosen-icon record store an opaque alias, not the accountId. The accountId is in one record per person (the person register), which can be looked up by accountId, as Atlassian’s guidelines ask.
• A scheduled function runs once a day and reports to Atlassian’s personal data reporting API the accountIds in the register, at most once per cycle: seven days by default (a parameter of the app).
• If Atlassian answers that an account is closed, the app deletes that person’s record. From then on the accountId no longer exists in the app’s storage and the alias left in the audit log, runs, locks, authorizations and the chosen-icon record can no longer be tied to a person by the app; the console shows that alias as a closed account. If Atlassian answers that the account was updated, the app only refreshes the date the record is current from: it holds no profile to update. The account unknown is never stored or reported.
• The audit log stays verifiable after an erasure: its hash chain covers the alias, not the accountId. This is pseudonymization with the key destroyed, not a rewriting of history: the entries stay (what was done, when, on which site) without a person attached.
• If the report fails, or Atlassian answers something unexpected, the function fails visibly (the invocation is recorded as failed in the app’s logs), applies what was valid and does not mark the report as done, so it retries on the next run. It does not continue silently.
• The time between an account being closed and its record being deleted depends on the reporting cycle above and on Atlassian’s own timing, so we do not commit to an exact figure.

What the app does not do. It has no function to erase a person on request before their account is closed: the only deletion is the one triggered by Atlassian’s report of a closed account. For such a request, write to the contact in section 1: we will answer with what we can technically do and tell you clearly what we cannot. Response time: within the period set by the applicable law. Procedure for erasing a person before their account is closed: the Customer’s site administrator writes to info@prodeoinnovation.com from their corporate address identifying the site and the person; we confirm the request and agree with the administrator on the steps available.

Prodeo cannot delete data from your installation’s storage directly: according to Atlassian’s documentation, a developer cannot delete it directly after uninstall; during use, the only deletion is the one the app itself performs as described above.

What you can do:

1. Uninstall the app from your site’s administration; Atlassian then applies the lifecycle in section 7.
2. Ask for access: any administrator with access to the GobernIA page can see the audit log entries on that same page.
3. Write to the contact in section 1 for any request.

9. Security

• The storage is protected by Atlassian’s measures (disk encryption and per-installation isolation, per its Forge documentation). We make no claim of our own about them.
• The app enforces a name perimeter: it can only create on the site elements whose exact name the model declares. Every denial is recorded.
• In a production installation, applying requires the Administer Jira permission, checked against Jira at the moment of applying; if the check cannot be made, the answer is a denial, recorded with its cause. This stops someone who is not an administrator; it does not stop an administrator, who can do by hand everything the app does.
• The audit log detects whether an entry was altered, and the seal carries a signature. They are not proof of non-repudiation: they protect against accidental alteration or tampering with the store by someone without the key, not against an administrator with access to the app’s storage.
• Security contact and security policy: info@prodeoinnovation.com (subject: «Security»).

10. Data Prodeo handles outside the app

Although the app sends us nothing, Prodeo may receive data by other routes:

• Support. Whoever writes to us gives us their name, email and the content of the case. Support channel: soporte@prodeoinnovation.com. Retention: for as long as needed to handle the case and up to two years after it is closed.
• Marketplace licences and transactions. As a partner, Atlassian may give us licence and contact information under the Marketplace Partner Agreement. This may include the licence details and the technical and billing contacts of the Customer; Prodeo uses them only to manage licences, provide support, invoice and send service communications, and keeps them while the licence is active and afterwards for as long as the law requires (for example for accounting purposes).
• International transfers. If Prodeo serves you from outside your country or the European Economic Area, support correspondence may cross borders. Prodeo operates from Costa Rica and its correspondence is stored in Microsoft 365; transfers rely on Microsoft’s contractual safeguards, including the standard contractual clauses where applicable.

11. Your rights

Depending on the law that applies to you (for example the GDPR or your country’s data protection law), you may have the right to access, correct or delete your data, and to object to or restrict its processing. To exercise them, write to the contact in section 1. For the data the app keeps inside your installation, section 8 says what is possible today. You may lodge a complaint with the data protection authority of your jurisdiction: in Costa Rica, the Agencia de Protección de Datos de los Habitantes (PRODHAB); elsewhere, the authority of your country.

12. Children

GobernIA is an IT administration tool for organizations; it is not directed at children.

13. Changes to this policy

We will publish the new version with its number and date. The new version applies from its effective date; where the applicable law requires it, Prodeo will notify material changes by reasonable means. If an app version starts to read or store new data (for example issues or users), this policy is updated before that version is released.