Only the data needed
Each step receives only the data required for its task. We do not request broader access simply because it is technically possible.
Security and data protection for AI systems
Before we build, we map the data, access, providers, retention, and risks. The final controls depend on the sensitivity of the data and the client's operating needs.
Four design principles
Least privilege
Roles, services, and integrations receive access only to approved sources and actions. Permission to read does not imply permission to change.
Human approval
A sensitive change can wait for review and approval. We set the approval rules according to the impact of an error.
Traceable actions
For important steps, we can record who or what started an action, its result, and whether a person approved it.
What we decide before development
Security design starts with the flow of data. Only then can we choose the cloud, model, permissions, and retention rules.
1
Sources and sensitivity
We list where the data comes from, who owns it, and whether it contains personal, contractual, or otherwise protected information.
2
Providers and location
We identify which services process the data, the region they use, and the contracts that apply.
3
Access and integrations
We define roles, approved sources, read and write permissions, and the actions that require human approval.
4
Retention and deletion
We decide what is stored, for how long, who can delete it, and what may remain in backups.
Controls throughout the project
Architecture
- Separate development and production environments
- Secrets kept outside source code
- Encrypted transfer and storage where required
- Limited roles for services and integrations
Development
- Changes reviewed by another developer
- Checks for vulnerable dependencies
- Tests for permissions, invalid input, and denied actions
- Test data without unnecessary personal information
Operations
- Availability and error monitoring
- Records of important access and changes
- A process for restricting access during an incident
- Regular review of roles and retention rules
What the solution design must state
One set of broad promises does not fit every project. We confirm the main choices in writing before work begins.
We do not hide these points inside a broad claim. We record them in the solution design and, where needed, in the contract and operating documentation.
Where the application and model run
Which providers and subprocessors receive data
Whether a provider may use data to train a model
How long inputs, outputs, and operating records are retained
Which roles may read, change, and delete data
Which actions require human approval
How access is restricted and service restored after an incident
Using AI with sensitive company data?
Tell us about the data sources, users, and required actions. We will propose the access, controls, and operating model.
Discuss solution security