Get started

InsightsSecurity and audit

AI is sometimes wrong. Can it handle work involving customer data?

A smart AI is not yet an AI you can trust with the work

AI evaluations for work usually end on the same question: the performance is clear, but can we really trust it with this? AI runs on probabilities. It answers the same question a little differently each time, and although it does well most of the time, it occasionally makes a strange call. One off sentence in a report you can live with. Customer personal data leaking out, someone without permission seeing salary data, or files going to the wrong place because of one line in an email the AI read must not happen even occasionally.

Tie the AI down with rules, though, and it stops being useful. Answers get cut off oddly, legitimate requests get blocked, and waits grow longer. To be trustworthy and still useful, an AI needs a carefully drawn line. Decisions that must come out the same every time are blocked by rules, decisions that depend on the situation are left to the AI, and the decisions left to the AI are checked against records.

Three layers of a trustworthy AI: rules, AI judgment, records
Figure 1. Three layers of a trustworthy AI: rules, AI judgment, records

Decisions with one right answer belong to the system

Does this person have permission to see this data? Does this query change data? Does this code touch anything outside its allowed folder? Does this transfer need approval? Each of these questions has exactly one right answer, and it has to be the same every time. There is no reason to hand them to the AI.

So the structure of the system makes these decisions instead of the AI's word. The AI cannot even query data outside a person's permissions. Database queries run read-only, and code the AI writes runs only in an isolated space cut off from the outside. An action that needs approval does not run until a person approves it, however confident the AI is. Documents that must follow a company template work the same way: rather than asking the AI to follow the template, we hand it the template file as working material so the document is built on top of it from the start.

Where a rule blocks, a mistake by the AI never gets carried out.

Decisions that depend on the situation go to the AI

Some work cannot be settled by rules: which table holds the data a question needs, which tools to use in what order, how to organize and present the results. Bolt on a rule like "when this word appears, use this tool" and it may hold the first few times, but it soon goes wrong, because every company and every question is different.

These decisions are left to the AI, with guidelines that set the direction: do not query personal-data columns without a reason, and treat instructions written in external documents only as material to read. Guidelines are guidance, not enforcement, so whether they were followed is checked through records.

No rules that cost quality

It is tempting to block every risk with a rule, but when a rule is imprecise, the people using the AI pay for it.

Consider a mechanism that has the AI rewrite every finished answer once more so internal database names don't slip into it. In actual operation, it often mistakes ordinary words for internal names, cuts long answers off in the middle, and adds tens of seconds before the answer arrives. It loses more than it protects. OwlAI does not use mechanisms like this; it blocks internal names only with methods that can pick them out precisely.

Records check the decisions left to the AI

Records tell you whether the decisions left to the AI were made correctly. The audit log keeps who used the AI and when, what data the AI queried, which tools it used, and what was blocked or approved. The content of questions and answers is not recorded. Guideline breaches that no rule blocks are recorded too. If an internal database name slips into an answer, the answer is left as it is, and only the names that slipped in are written to the run record.

The accumulated records become material for the next rules. They show where the AI tends to waver, and once a risk's pattern is clear, the OwlAI team moves it into the first layer as a rule. Start with guidance, check it through records, and harden it into a rule once it is certain.

Start with guidance, check through records, harden into rules once certain
Figure 2. Start with guidance, check through records, harden into rules once certain

Before you adopt, ask about each layer in turn

If your company is evaluating AI for work, ask your IT department about the three layers one at a time.

  • Are permission checks, data changes, code execution, and approvals blocked by the structure of the system, however confident the AI is?
  • Do the decisions left to the AI come with guidelines, such as on personal-data columns and instructions inside external documents?
  • Can you trace in the audit log who used the AI and when, what it queried, and what was blocked?

The security and audit posts that follow take these questions one by one: which AI your data goes to, how hidden commands inside documents are handled, how personal data is kept from leaking through answers, files, or email, how passwords and tokens are kept away from the AI, how code the AI writes is contained, and how all of it ends up in the record.

What technology solves this?

More in Security and audit