Most large organisations now have an AI policy. The harder question is whether their AI systems are technically capable of breaking it.
Increasingly, the answer is yes. Research released by EY on 15 September surveyed 202 senior AI decision-makers at large US public companies. Almost all 98% said their organisations had formal AI governance policies.
But 47% also said their organisations had previously bypassed their own AI governance processes for urgent deployments.
Among respondents whose organisations use agentic AI, 49% said their governance frameworks had not yet been updated specifically for the risks and requirements of agents. The sample is US-based and should not be treated as representative of every organisation. But the underlying problem extends well beyond the US.
AI governance is moving from a policy problem to an execution problem.
A policy describes intent. A control enforces it.
A policy can tell an AI agent what it should do. A control determines what it can do.
That distinction mattered less when generative AI primarily answered questions. It matters much more when an AI system can open documents, query databases, call APIs, update CRM records, execute code or instruct another agent to perform a task.
Consider a simple policy:
Customer information may only be accessed by authorised users for legitimate business purposes.
That is perfectly reasonable governance. Now give an AI agent credentials that allow it to query the entire customer database. The policy still exists and so do the credentials.
If the organisation wants that policy to survive contact with an autonomous system, the rule has to become something the technology can enforce.
- Which customer records may this agent access?
- For which task?
- Using which identity?
- For how long?
- Can it export the information?
- Can it pass the data to another agent?
- Can it send the output outside the organisation?
- Which actions require a person to approve them?
A governance document cannot answer those questions at runtime. Architecture can.
That means translating governance into mechanisms such as scoped credentials, least-privilege access, agent identities, tool permissions, approval gates, data boundaries and audit logging.
The policy defines the rule. The control makes the rule real.
Agents collapse the distance between decision and action
Traditional enterprise governance often assumes there is some separation between deciding and doing.
A person requests access.
Someone approves it.
An employee logs into a system.
The action is performed.
Logs record what happened.
Agentic systems can compress much of that sequence.
An AI agent can interpret a task, choose a tool, perform an action, inspect the result and decide what to do next, sometimes within seconds.
In a multi-agent workflow, it may also delegate work to another agent, receive a response and continue without a person being involved in each step.
That is part of what makes agentic AI useful. It is also why governance designed around occasional human decisions can struggle.
EY found that 85% of surveyed executives at organisations using agentic AI said at least some of their agents execute actions without real-time human involvement.
More strikingly, 26% said their organisations could not detect unauthorised AI agents operating internally.
That is not simply a policy problem. It is a visibility and control problem.
If an organisation does not know which agents are operating, what identities they are using, which tools they can access or what actions they have taken, the quality of its governance framework matters far less than it appears to on paper.
Governance has to exist at runtime
Enterprise technology is already moving in this direction. We are starting to see governance controls separated from the individual AI agent and placed into a layer around it. That architecture matters.
If every AI agent implements its own access rules, logging, approvals and security controls, an organisation quickly ends up with dozens of different interpretations of the same governance policy.
A stronger model is to place a control layer between AI systems and the resources they can reach.
The agent requests an action.
A control layer evaluates whether that action is permitted.
The organisation defines the rules.
The underlying system enforces them.
This also makes governance easier to change.
If a policy changes, the organisation should not need to rewrite the behaviour of every AI agent individually. It should be able to change the control governing access to the underlying system.
Human oversight should follow consequence
Putting governance into the workflow does not mean a manager should approve every AI action. That would remove much of the value of automation. The better distinction is consequence.
An agent summarising an internal document may be allowed to operate autonomously.
An agent drafting a customer email might work autonomously until the point of sending.
An agent recommending a refund could prepare the transaction but require approval before money moves.
An agent changing employee access rights may require a much stronger approval process.
So the useful governance question is not:
Should AI be autonomous?
It is:
Autonomous to do what?
The answer should be different for each action. Good AI governance therefore needs to operate at the level of permissions and consequences, not simply at the level of applications.
South African businesses do not need to wait for an AI Act
South Africa does not currently have a comprehensive AI Act requiring businesses to build this kind of architecture. But existing responsibilities do not disappear when AI becomes involved. Where an AI agent processes personal information, POPIA remains relevant.
Businesses still need appropriate safeguards around the personal information for which they are responsible.
Contracts may impose additional controls. Banks, healthcare organisations, insurers and other regulated businesses may also have sector-specific obligations. There is another practical issue.
South African companies may encounter enforceable AI requirements through their customers and contracts long before equivalent requirements appear in domestic legislation.
A European customer does not need the EU AI Act to apply directly to a South African supplier before asking how that supplier’s AI systems access its information. It can put the requirement into the contract.
For South African technology companies serving international customers, procurement may therefore become a major driver of AI governance.
The questions are likely to be practical:
- What data can your AI access?
- Where is that data processed?
- Who or what can access it?
- What happens when an agent attempts an unauthorised action?
- Can access be revoked?
- Can you show us what the system did?
Those are architecture questions as much as compliance questions.
Governance does not end at deployment
Passing an initial AI review is not the same as remaining governed. EY’s research offers an interesting indication of why.
Among surveyed organisations conducting formal AI assurance reviews, 64% said those reviews had caused them to significantly modify at least a quarter of their AI systems. Twenty-nine percent had paused at least a quarter.
Twenty-five percent had completely stopped at least a quarter. Again, these numbers belong to one specific US sample.
But the principle matters.
AI systems change.
Models change.
Data changes.
Integrations change.
Permissions accumulate.
Employees find new uses.
Agents gain new tools.
A system that was appropriately governed when it was approved may not remain appropriately governed six months later. Organisations therefore need more than an approval record. They need the ability to reconstruct what their AI systems actually did.
- Which identity performed the action?
- Which information did it access?
- Which tool did it call?
- Which permission allowed the action?
- Was human approval required?
- What information left the system?
- What changed afterwards?
Without that evidence, an organisation can describe how an AI system was supposed to behave. It cannot necessarily demonstrate how it actually behaved.
From governance documents to governed infrastructure
This principle also informs how we think about RebelCore. We do not believe AI governance can exist only in documentation around an AI system. It has to exist in the architecture between AI models, business information and the systems on which agents are allowed to act.
Permissions should determine what information an agent can see.
Approval points should control consequential actions.
Audit logging should provide evidence of what occurred.
Deployment choices should determine where sensitive workloads run and where company data is allowed to go.
None of this replaces governance policy.
Policies remain essential because people still need to decide the rules.
But as AI systems become increasingly capable of acting rather than simply answering, those decisions have to be translated into technical boundaries the machine cannot simply step around.
So the next time someone presents your organisation’s AI governance framework, ask one additional question:
Where, technically, is each rule enforced?
If nobody can point to the answer, it may not be a control at all. It may simply be an instruction.
