AI has the potential to fundamentally change how businesses operate. But there is a difficult question at the centre of almost every proposed AI-first system: how much business information can safely be shared with the intelligence that needs to process it?
An AI assistant summarising a public document presents relatively limited information security concerns. An AI agent working across contracts, commercial records, personnel information, intellectual property and operational systems presents a very different problem.
For AI to become genuinely useful across an enterprise, it needs context. Yet that context frequently consists of information the organisation has spent years protecting.
The central challenge is giving AI sufficient access to be useful without surrendering control of the information it uses.
The risk is bigger than model training
Concerns about AI providers using customer information to train their models are understandable, but model training is only one consideration.
Information submitted to an AI service may be processed, transmitted, retained temporarily, recorded in logs or made accessible to supporting infrastructure and service providers. The precise arrangements depend on the provider, product, configuration and contractual terms.
Even where information is excluded from model training, questions remain about where it is processed, how long it is retained, who can access it and what happens when it is deleted.
There are also risks within the application itself.
An AI agent might retrieve information beyond a user's permissions, expose confidential material in an otherwise legitimate response or follow malicious instructions embedded in a document.
As agents become capable of taking actions rather than simply answering questions, the potential consequences extend from information disclosure to unauthorised changes in business systems.
These are not reasons to reject AI. They are reasons to reconsider how AI systems are architected.
Bringing intelligence to the information
Many current AI workflows involve copying information into a model's context so that it can perform a task.
An alternative architectural approach is to keep authoritative business information within controlled systems and allow AI to access only the information required for a specific operation.
Consider an AI agent assessing the potential consequences of a supplier delay.
It may need the relevant contractual milestones, current schedule, installation dependencies and reported progress. It does not necessarily need the entire contract repository, unrelated commercial negotiations or personal information about the delivery team.
A controlled information layer could identify and provide the necessary context, applying the organisation's existing access permissions and information classification rules.
AI would still process the information it receives, and external processing would still require appropriate safeguards. But the amount and sensitivity of information exposed could be substantially reduced.
The objective is not necessarily to keep every AI model within the enterprise's own infrastructure. Different deployment models, including private environments, managed services and externally hosted models, may be appropriate for different information classifications.
The important requirement is that the organisation can determine and verify where information is processed and under what conditions.
Context preservation creates another security responsibility
Persistent context is essential to efficient multi-agent systems. Without it, agents repeatedly interpret the same material, lose decisions and reconstruct information unnecessarily.
But a shared context system also becomes a valuable concentration of potentially sensitive information.
Its contents may reveal relationships that are not obvious from individual records. Separate commercial, operational and personnel records can become significantly more sensitive when combined.
The semantic information layer therefore needs its own security model.
Access controls must apply not only to original documents, but also to extracted facts, inferred relationships, summaries and generated outputs.
An agent authorised to understand programme progress should not automatically gain access to confidential commercial negotiations simply because both relate to the same project.
AI-generated knowledge needs to inherit the security obligations of the information from which it was derived.
This is a particularly important consideration for systems where multiple specialised agents share a continuously maintained understanding of the business.
Control of actions matters as much as control of information
An AI system that can only analyse information presents a different risk from one that can approve changes, update financial records, modify permissions or instruct suppliers.
Enterprise AI needs clear separation between interpretation, recommendation and authorised execution.
AI may identify that a contractual milestone is at risk, prepare an impact assessment or propose a change. That does not mean it should have the authority to approve the change or modify the contract.
Permissions should be enforced by the underlying business system, not simply described to the model through instructions.
Significant actions should require appropriate authorisation, with records of the information considered, the decision made and the resulting change.
This also makes it possible to replace or upgrade AI models without transferring business authority into the model itself.
What enterprise acceptance requires
For AI-first systems to become routine enterprise infrastructure, security and governance need to become inherent characteristics of the architecture.
Several capabilities are particularly important:
- Information control: Clear classification, access permissions, data minimisation and separation between customers and security domains.
- Processing transparency: Verifiable arrangements for data location, retention, subprocessors, model training and deletion.
- Controlled execution: Defined agent permissions, bounded operations and independent authorisation for consequential actions.
- Traceability: Evidence of which information informed an output or action, including the models, tools and policies involved.
- Operational assurance: Monitoring, security testing, incident response, model-change management and the ability to suspend or contain agent activity.
- Independent verification: Security controls and governance arrangements that can be assessed against recognised standards and contractual requirements.
Privacy legislation, confidentiality obligations and sector-specific requirements remain relevant. An AI system does not become compliant simply because its provider offers an enterprise subscription or promises not to train on customer data.
These requirements will differ across industries and information classifications. A construction programme, financial institution and defence contractor will not necessarily accept the same processing arrangements.
Enterprise readiness therefore requires configurable and demonstrable controls, not a universal declaration that a system is secure.
Towards a different architecture of trust
The emerging opportunity is to separate three things that are often combined in today's AI applications: the authoritative information, the intelligence interpreting it and the authority to act.
The enterprise information system maintains records, permissions, history and business rules.
AI provides interpretation, reasoning and specialised capabilities, using controlled access to the relevant context.
A separate execution layer validates and authorises consequential actions.
This separation would allow different AI models and providers to be used according to the requirements of each task, without making any individual model the permanent custodian of enterprise information or business authority.
It would not eliminate security risks. The information layer, AI services, integrations and execution controls would all remain potential points of failure.
But it would allow those risks to be managed through explicit architectural boundaries rather than relying principally on a model's behaviour or a provider's assurances.
The question for enterprise AI is not simply whether the model can be trusted. It is whether the system can remain trustworthy when the model makes a mistake, is compromised or is replaced.
That may be one of the defining requirements for AI-first systems to move from useful experiments to dependable enterprise infrastructure.