Answer the hard questions before someone asks them
Who can see what. Where the data goes. How long it is kept. What the system decided, and on what basis. We build those answers into how the system runs, so producing them is a lookup rather than an archaeology project.
In short: We work on access, data flow, retention, and the decision record — the four things you get asked about. We also scope agent permissions tightly, because prompt injection is a real risk wherever a system reads untrusted text and can act on it. Where a question is genuinely legal, we say so and point you at a lawyer.
Four questions worth being able to answer today
Whether the person asking is a customer, an auditor, a security reviewer at a prospect, or your own board, the questions land in the same four places. Most teams can answer roughly. Roughly is fine right up until the moment it is not. The work here is turning approximate answers into ones backed by configuration you can show.
Who can see what
Access at the level of records, not just systems. A retrieval tool that can read every document in the company is a permissions problem waiting for its moment.
Where the data goes
Which providers process what, in which regions, under what terms, and whether anything is retained or used for training on their side. Written down, per connection.
How long it is kept
Prompts and outputs are records. Retention needs to be a deliberate setting with deletion that actually runs, rather than logs quietly accumulating forever.
What the system decided
A log of inputs, outputs, model version, and any human action taken afterward. Enough to reconstruct one specific case months later without guesswork.
Keeping documentation is much cheaper than rebuilding it
Rules around AI systems have moved fast over the last few years, and they are still moving. We are not going to pretend to know exactly what will be required of your organization in two years. What we can say with confidence is that every version of the answer starts from the same material: what the system does, what data it touches, how it was evaluated, what it decided, and who approved it going live.
Write that down as you go and it costs a small amount of effort per change. Try to assemble it eighteen months later, after the person who built it has left and the evaluation notes lived in someone’s local folder, and it becomes a genuinely painful project. We keep a short, current record instead — a system description, a data flow map, an evaluation history, and a decision log. Short and accurate beats thorough and out of date.
Prompt injection is a permissions problem
If your system reads text it did not write — customer emails, uploaded documents, web pages, ticket bodies — then that text can contain instructions. And if the same system can also do things, like send messages, update records, or call other tools, those instructions can be acted on. This is not theoretical and it is not solved by asking the model nicely to ignore instructions in the content. Filtering helps at the margins. It is not a boundary.
So we design assuming an injection will eventually succeed, and make sure the consequences are small. Read access is scoped to what the current user is already entitled to see. Write actions are limited, and the ones that matter require a person to confirm. Anything irreversible or externally visible gets a human in the path. Actions are logged so an odd sequence can be found afterward. The question we care about is not whether the model can be tricked, but what a successful trick would let it do. Systems built with agent capabilities need this thinking most, because they are the ones with hands.
Where you need a lawyer, and we will tell you
We are engineers. We can build the controls, produce the evidence, and make the system behave the way your policy says it should. What we cannot do is tell you which regulations apply to your organization, whether a particular use is lawful in a particular market, or what your contracts and disclosures need to say. Those are legal questions with real consequences and they need a qualified lawyer in your jurisdiction.
In practice the split works well. Your counsel decides what the obligations are. We make the system meet them and produce the records that show it does. When something in a requirement is technically ambiguous, we will write down what we think it means and hand that to your lawyer rather than quietly picking an interpretation on your behalf.
What we won’t do
Give you legal advice
We will not tell you which laws apply to you or whether a use case is permitted. We will build to the requirements your lawyer sets and flag anything that looks like it needs their opinion. Engineering confidence is not a substitute for counsel.
Claim a system is injection-proof
Nobody can honestly promise that while models take instructions in the same channel as content. We reduce what a successful injection can reach and we log enough to find it afterward. Anyone selling you immunity is overstating what is possible.
Produce documentation for its own sake
A hundred page policy pack that nobody updates is worse than four pages that are true this week. We would rather write less and keep it current than hand you something impressive that quietly stops matching reality.
Could you reconstruct one AI decision from six months ago?
If the answer is not a confident yes, that is the gap worth closing first. Tell us what the system does and who is asking questions about it.
It matters wherever a system reads text it did not write and can also take actions. Customer emails, uploaded files, ticket bodies and web pages can all carry instructions. If your setup only reads and returns text to a person, the risk is lower. If it can send, update or call other tools, scope those permissions tightly and put a person in front of anything irreversible.
Do you provide compliance certification?
No. We are engineers, not auditors or lawyers. We build the controls, produce the evidence and keep the documentation current so that an audit or a security review has something real to work from. The certification itself comes from the appropriate body, and the question of which obligations apply to you belongs with your counsel.
What should we log about AI decisions?
Enough to reconstruct one specific case later: the input, the output, the model version, the time, and what a person did with it afterward. That set answers most questions people ask. Log more than that and you create a retention problem of your own, so we set deletion rules at the same time as we set up the logging.
Can we use a third-party model and still keep control of our data?
Often yes, but it depends on the provider terms, the region, and what your own obligations require. The work is reading the actual terms per connection, checking whether anything is retained or used for training, and writing that down where your team can find it. Where the answer is unclear, that is a point to take to your lawyer rather than assume.
