The EU AI Act, being phased in since 2024, is blunt about a point almost no company meets today: whoever operates a high-risk AI system must assign human oversight of it to a named person — not a department, not "the IT team", but someone with real competence, training and authority over that specific system.
The international AI management standard, ISO/IEC 42001, asks for the same thing through a different door: to qualify, a company must document who answers for each role in its AI use and how that responsibility reports up to leadership. The United States government's AI risk guidance asks that every team and every individual involved have a defined role, not just the organization as a whole in generic terms.
The pattern across all three is the same: accountability for an AI system needs a first and last name attached to it. In practice, at Brazilian and Latin American companies, that almost never happens — and that gap is what this piece unpacks.
The agent no one remembers building
A marketing team builds, with an AI tool, an agent that answers customer questions about the return policy. The person who set it up moves to another team six months later. The agent stays live, still answering, because no one turned it off — and no one has an obvious reason to turn off something that "is working."
That is the orphan agent: it runs, but it has no owner. No one knows what data it was trained on, what policy it follows, whether that policy is still current, or who should be alerted if it starts answering something wrong. It never appears in any inventory because it never needed formal approval to be born — and so it never needed formal approval to keep running, either.
The problem scales with the number of agents. A company that has five agents scattered across different teams today, with no central inventory, tends to have twenty a year later — each one built by a different person, solving a one-off problem, with no one ever deciding this as a policy. Employees turning to personal AI tools on their own is already a known risk; the orphan agent is the same logic applied to a system that keeps running inside the company after whoever built it is gone.
McKinsey's data shows the size of the vacuum underneath this: among companies already using AI, only 28% report that the CEO personally takes direct responsibility for AI governance. If top leadership rarely takes on that responsibility explicitly, it is reasonable to assume an agent built by someone in the middle of the org chart has even less chance of having a formal owner behind it — and zero chance of surfacing in an audit no one knew it needed.
When a policy finds no one
The most common response to this problem is publishing an AI use policy — a document saying what can and cannot be done with these tools. That helps, but it does not solve the orphan agent, because a policy addresses people's behavior, not the ownership of each system running in production.
A policy says "every AI-driven automation must follow the company's security guidelines." It does not say who, specifically, gets alerted if that automation starts acting outside expectations. Without a name tied to each agent, the policy becomes a correct document that no one can actually apply to a concrete case, because no one knows whom it applies to at that moment.
The EU AI Act is explicit about this distinction: a written rule is not enough — a named person needs competence over that specific system, training on how it works, and the authority to suspend it if something goes off script. Three conditions a generic policy, by itself, hands to no one — because a policy speaks to everyone and, for that very reason, speaks to no one in particular.
There is a third, quieter problem: even where a named owner exists on paper, there is rarely a process to transfer that responsibility when the person changes roles. The agent outlives the departure of whoever created it because a person's exit and an agent's lifecycle run on completely separate tracks inside the company.
What has to be in place
An agent with a real owner rests on verifiable mechanisms, not goodwill or institutional memory.
A named owner per agent, not per department. Every agent has a person, or a specific role within a team, attached to it from the moment it is created — visible in any inventory, not guessed at when something goes wrong.
A declared scope at the agent's creation. What it can access, what task it solves, and which knowledge source it works from get recorded alongside the agent, not just in the head of whoever configured it that day.
Human approval before a sensitive action. When the agent goes beyond answering — when it executes something with a real effect on a system or a document — the action pauses and asks a person to confirm, right inside the conversation.
Formal handoff when the owner changes roles. Before someone leaves a function, the agents under their responsibility get reassigned to someone else — the same discipline already applied to a financial system or an admin account cannot be missing here.
An audit trail per agent. Who created it, who approved its scope, when the owner changed, and what the agent did stay recorded and searchable — the difference between reconstructing a decision in minutes and not being able to reconstruct it at all.
This is how Skyller was designed: every agent is born with a declared scope, human approval available for sensitive actions, and an audit trail that follows it through its whole life, from creation to shutdown.
What the team gains from this
Naming an owner per agent is not extra bureaucracy — it is what lets an agent be reused with confidence instead of abandoned out of caution the moment its creator moves on. A team that knows exactly who answers for each automation can extend its use to other departments without inheriting an unknown risk along with it.
The reverse effect matters too: when an agent clearly belongs to someone, that person has a real reason to review it, update it, and shut it down once it stops making sense. An agent with no owner is never shut down — it is only forgotten, and it keeps consuming access and credentials while no one notices it is still there.
There is also a time-to-resolution gain during an incident. When an AI system behaves unexpectedly, the first question in any investigation is "who owns this." A company that already knows the answer resolves the incident in hours; one that first has to figure out who built the agent loses the most expensive kind of time there is: the gap between the problem starting and someone realizing there is an owner to be found.
Questions to bring to the next meeting
- How many AI agents are in use today across the company, and how many have a written, named owner? If the second question is hard to answer, the inventory does not really exist.
- What happens to a person's agents when they change teams or leave the company? If the answer is "nothing, usually," those agents are already potential orphans.
- If an agent starts acting outside expectations tomorrow, who gets notified first? If the answer takes a while, that is a sign authority over that system was never assigned to anyone.
- Is there a process today to transfer ownership of an agent when the original owner leaves the role? If not, every agent in the company is one departure away from becoming an orphan.
