--- title: "Governance and control for AI agents | Atiende" description: "Governance and control for AI agents: who has access, what they can do, when approval is needed and how each result is reviewed before it is trusted." url: https://useatiende.ai/en/producto/gobernanza lang: en alternates: es: https://useatiende.ai/es/producto/gobernanza en: https://useatiende.ai/en/producto/gobernanza updated: 2026-10-06 --- # Visible boundaries. Identifiable owners. Controls are designed alongside the process: who has access, what they can do, when approval is needed and how outcomes are reviewed. Trust requires evidence of behavior, not a label. ## Permissions tied to the work Access is defined by role, organization and action. Reading information is not equivalent to modifying it, and authorization for one file does not implicitly grant access to all. Permissions are tested with positive and negative scenarios to confirm the system also rejects requests when appropriate. ## Approvals proportionate to impact An informational answer and a balance change do not need the same level of control. The design classifies actions by impact and reversibility and establishes when a person must intervene. Approval includes enough context and is linked to the version of the action that will actually be executed. ## Records that support investigation Understanding an outcome requires consulted sources, attempted actions, tool responses and relevant human decisions. The design defines what to record and for how long, avoiding unnecessary data retention. The aim is to reconstruct the process and correct failures without turning observability into an indiscriminate copy of sensitive information. ## Evaluation before and after launch The test set includes frequent cases, source errors, unauthorized requests and context changes. Findings have an owner and a decision: fix, limit or defer. After launch, samples and exceptions are reviewed to maintain quality as data, tools or procedures change. ## How controls are evaluated in a pilot A control is demonstrated by trying to break it. Besides confirming that an authorized user can do their job, the test checks that someone without permission is refused, that an instruction hidden in a document does not widen actions and that a stale approval is not reused. Requests that cross customers, queries for sensitive data and out-of-hours changes are simulated. Each finding gets an owner and a decision: fix, limit or defer. - Correct refusal of requests that must not be served. - Approval tied to the exact version of the action executed. - Records sufficient to reconstruct who did what and with which source. - Findings with an owner and decision date, not merely noted. ## What to prepare beforehand Governance rests on decisions that only the organization can make. Before configuring anything, it helps to define which data is sensitive, which actions count as high impact and who has authority to approve them. Security, legal or compliance teams, where they exist, should take part from the start and not at the end. You also need to agree how long each record is kept, balancing usefulness for investigations against data minimization. - Classification of data by sensitivity and who may see it. - A list of high-impact actions and their approvers. - Internal or sector requirements that apply to the process. - Desired retention periods for records and conversations. ## Limits and human oversight Controls reduce risk but do not eliminate it, and this page is not a certification or a compliance opinion. What your sector requires is confirmed with your own specialist team and the applicable regulations. Human oversight continues after launch: samples, exceptions and access are reviewed, and permissions are adjusted when data, tools or the people involved change. - Periodic review of samples, exceptions and access granted. - Escalation to a person when uncertain or when risk is high. - No attribution of certifications without verifiable evidence. ## Questions for your team before you start It is best to answer them with the people who answer for risk, not only with the operations team. - Which mistakes would be unacceptable even if they were rare? - Who can stop the system if something goes wrong? - What evidence would we be asked for in an internal audit? - Which data should not be stored in any log? - How often will we review permissions and samples? ## How it works 1. Identify data, actions and risks for the specific process. 2. Define permissions, approvals and escalation criteria. 3. Test permitted behavior and requests that must be rejected. 4. Review operational evidence and adjust scope when necessary. ## Frequently asked questions ### Does Atiende have published security certifications? Certifications are not claimed without verifiable evidence. Each project’s security requirements are reviewed against its specific architecture, providers and controls. ### Can we require approval for certain actions? Yes as a design requirement. Actions, authorized people and verification that the executed outcome matches approval are defined. ### Where is data stored? Location depends on agreed architecture and providers. Residency, retention and access are documented before real information is used; this page does not assume a default region. --- Book a demo: https://useatiende.ai/en/demo Contact: ventas@useatiende.ai · https://useatiende.ai/en/contacto Sitemap: https://useatiende.ai/sitemap.xml · llms.txt: https://useatiende.ai/llms.txt