Security and privacy in artificial intelligence systems

An AI system shouldn’t receive more information than it needs to solve a task.

We apply the minimization principle to limit the context sent to models and external services.

Depending on the project we can:

• select only the fields needed
• exclude sensitive information
• anonymize data or separate it from the person
• limit retention
• keep different sources apart
• apply access controls
• set different policies by type of information

This cuts unnecessary exposure and makes the system easier to control.

The principles of data minimization, purpose limitation, and integrity and confidentiality are part of the GDPR and of data protection by design.

Not every user should be able to look up the same information.

We can apply permissions by:

• user
• role
• department
• organization
• company
• location
• project
• asset
• type of documentation

For example, an internal assistant can be connected to thousands of documents and return only the ones the user is authorized to see.

AI shouldn’t become a back door around existing permissions.

It has to respect them.

An agent can look up information.

But it can also use tools and take actions.

For example:

• create a record
• change an appointment
• update a CRM
• open an incident
• send a message
• run a query
• start a workflow

Not all those actions carry the same risk.

That’s why we define levels of action.

A low-impact operation can run automatically.

A sensitive action can require:

• additional checks
• business rules
• limits
• user confirmation
• human approval

AI interprets and code executes.

And the rules decide when an action is allowed.

A language model is probabilistic.

It can misread a request or produce a wrong answer.

That’s why we avoid architectures where the model directly controls critical processes with no mechanisms in between.

We can build in:

• limited tools
• structured responses
• validations
• lists of allowed operations
• limits on amount or scope
• states
• permissions
• confirmations
• human intervention

The goal isn’t to get a model that never makes mistakes.

It’s to design the system so a model error doesn’t automatically turn into an operational error.

An agent doesn’t need unlimited access to a database.

We can design intermediate layers that control:

• which tables it can query
• which fields it can use
• which operations are available
• which filters have to apply
• which users can access it
• which queries get logged

When the risk justifies it, we prevent the model from generating and running arbitrary SQL directly against production systems.

Instead, it can work through specific tools and controlled queries.

A system connected to business documentation has to control both what it retrieves and who can retrieve it.

We can apply:

• filters by user
• permissions by document
• metadata
• separation between organizations
• version control
• authorized sources
• references to the original document

A RAG system shouldn’t assume that every indexed document can be shown to anyone.

Retrieval has to respect the same restrictions as the rest of the organization.

AI for internal documentation and corporate knowledge →

Not every project needs the same model or the same provider.

The choice can depend on:

• privacy
• where processing happens
• how data is handled
• performance
• cost
• latency
• technical capability
• corporate requirements

We can also design architectures that reduce dependence on a single provider.

Business logic can be kept separate from the model to make changes easier when they’re needed.

Some projects require a higher level of isolation.

Depending on the case, these can be used:

• controlled cloud environments
• the client’s own infrastructure
• private networks
• separate storage
• private models
• components deployed inside the corporate infrastructure

Not every project needs this level of complexity.

The architecture has to be proportionate to the risk, the data used and the process we want to automate.

When an automation makes decisions or takes actions, we need to be able to reconstruct what happened.

We can log:

• user
• request
• tools used
• information consulted
• actions taken
• errors
• states
• times
• results

This makes it easier to handle:

• audits
• incident resolution
• evaluation
• system improvement
• analysis of unexpected behavior

A business AI system shouldn’t be a black box nobody can investigate.

A solution’s behavior has to keep being analyzed after launch.

We can monitor:

• errors
• exceptions
• latency
• tool usage
• model cost
• wrong answers
• handovers to people
• share automated

Real cases reveal situations that don’t show up during testing.

That’s why taking AI to production also means building ways to observe it.

Human oversight doesn’t mean a person has to review every operation.

It means defining when a person has to step in.

For example:

• not enough information
• an ambiguous result
• a sensitive operation
• an unforeseen exception
• a request outside the scope
• high risk
• an amount above a set limit

The rest of the process can continue automatically.

Human intervention should be used where it adds control, not as a stand-in for a badly designed automation.

A business system has to be ready to fail.

An API can stop responding.

A document can be incomplete.

A user can enter wrong data.

A model can misread a request.

That’s why we design paths to:

• retry
• stop
• log
• alert
• ask for information
• hand over
• restore the previous state

The difference between a demo and a system in production usually shows up exactly when something goes wrong.

Every integration widens what the system can do, and also its exposure to risk.

Before connecting an application we analyze:

• authentication
• permissions
• available operations
• reachable information
• usage limits
• credential management
• behavior when errors occur

We apply the principle of least privilege.

If an integration only needs to read certain information, it shouldn’t have permissions to change the whole system.

In manufacturing, energy and other critical environments, integration calls for an extra level of caution.

It may be technically possible to use information from OT or SCADA systems, but the architecture has to analyze specifically:

• segregation
• cybersecurity
• permissions
• intermediate controls
• isolation
• the potential impact of each action

We don’t give a model direct access to critical systems without a specific architecture that limits and controls what it can do.

AI for manufacturing and industry →

AI for energy and utilities →

When a system processes personal data, the design has to take into account the applicable data protection principles and obligations.

Among them:

• lawfulness and transparency
• purpose limitation
• data minimization
• accuracy
• storage limitation
• integrity and confidentiality
• accountability

The technical architecture can help put these principles into practice, but determining the legal basis and the specific obligations of each processing activity requires legal advice, and that assessment isn’t something we do.

The EU Artificial Intelligence Act sets different obligations depending on the system, its purpose, its level of risk and the role each organization plays.

Since 2 August 2026, among others, the transparency obligations in Article 50 apply to certain AI systems. In some cases these include telling a person when they’re interacting directly with an artificial intelligence system.

That’s why we can build in elements such as these from the design stage:

• transparency
• traceability
• human oversight
• permissions
• documentation
• limits on actions

The specific obligations have to be assessed according to the use case and the organization’s role.

Architecture can make compliance easier. It doesn’t replace legal analysis when that’s needed.

Not every project carries the same level of risk.

The architecture has to adapt especially when we work with:

• health
• infrastructure
• financial information
• confidential documentation
• personal data
• contract information
• strategic knowledge

For example, in healthcare we mainly aim our systems at administrative, operational and information-access processes.

We don’t use an agent to replace diagnosis or clinical judgment.