Many companies want AI assistance but cannot allow sensitive data to move through uncontrolled tools. The concern is valid. AI workflows may involve customer data, employee information, business documents, intellectual property, contracts, operational records or regulated material.
The answer is not necessarily to avoid AI. The answer is to design data boundaries before building the workflow.
Define the data boundary
Start by identifying what data the workflow needs and how sensitive it is.
Questions include:
- Does the workflow use personal data?
- Does it include confidential business information?
- Are there contractual restrictions?
- Are there sector or regulatory requirements?
- Can the data be anonymised or minimised?
- Which users are allowed to see it?
- Which providers are approved to process it?
- Should prompts and outputs be retained?
This should happen before selecting a model or provider.
Use approved environments
Some AI services provide enterprise controls around data use, retention and access. For example, AWS states that Amazon Bedrock customer content is not shared with model providers or used to improve base models, and OpenAI describes business data controls for enterprise and API products. The exact terms and configuration should always be verified for the specific product and contract.
The practical point is that companies need approved environments, not ad hoc usage. A public chatbot used through individual accounts is not the same as a controlled enterprise setup.
Minimise what the AI sees
Safe AI workflow design should limit input data to what the task requires. Do not send full records if a small excerpt is enough. Do not expose all documents if the workflow only needs approved policy material. Do not give tool access where a read-only suggestion is sufficient.
Useful patterns include:
- retrieval from approved sources;
- role-based access;
- data masking;
- structured inputs;
- narrow task scope;
- source citation;
- human approval;
- logging.
Control system actions
The most important boundary may not be data input. It may be action. If an AI system can update records, send messages or trigger workflows, the risk increases.
OWASP’s LLM application risks include excessive agency, insecure plugin design, sensitive information disclosure and overreliance. These risks become relevant when AI tools connect to business systems.
A safer design separates suggestion from action:
AI prepares output → user reviews → system executes approved actionMonitor and maintain
Safe AI workflows require ongoing operation. Data sources change, permissions change, prompts change, models change and business rules change. The workflow should have an owner, logs, review routines and a way to adjust behaviour.
This is why AI implementation belongs close to software operation, not only experimentation.
Avoid overclaiming “secure AI”
No implementation is secure simply because it uses AI or because it runs in a particular cloud. Security depends on architecture, configuration, access control, data handling, monitoring, contracts and user behaviour. A responsible article or proposal should be specific about what is controlled and what is not.
Memory(One) perspective
Memory(One) should help companies build AI-assisted workflows with practical data boundaries: approved systems, access control, human review, integration discipline and operational ownership. The goal is to make useful AI possible without losing control of sensitive information.
Sources and inspiration
- CPHD Nordic — Claude in the company with AWS Bedrock: https://www.cphdnordic.com/indsigter/claude-i-virksomheden-saadan-kommer-i-sikkert-i-gang-med-aws-bedrock
- AWS — Security and privacy in Amazon Bedrock: https://aws.amazon.com/bedrock/security-compliance/
- OpenAI — Enterprise privacy: https://openai.com/enterprise-privacy/
- OWASP — Top 10 for Large Language Model Applications: https://owasp.org/www-project-top-10-for-large-language-model-applications/
- NIST — AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework