> ## Content Index > Fetch the complete content index at: https://onchain-fx.ghost.io/llms.txt > Use this file to discover other available public pages before exploring further. # What an AI needs before you let it operate - URL: https://onchain-fx.ghost.io/what-an-ai-needs-before-you-let-it-operate/ - Published: 2026-09-18T00:51:59.000Z - Updated: 2026-09-18T00:51:59.000Z - Description: A model can be brilliant and still not be safe to operate. Ten things an AI needs before you hand it the keys, drawn from operating system design and from watching agents work inside a live financial operation. - Author: Guilherme Bissoli - Tags: Operating Notes, #lang-en I wrote last time about the difference between a database and an operating system. A database tells you what is stored. An operating system tells you what is happening now, what changed, and what needs attention next. That piece was about the company. This one is about the AI itself. Because the moment you let a model do more than answer questions, a second question shows up immediately. Not "is it smart enough." Something narrower and much less comfortable. Is it safe to let this thing act. Those are not the same question. I found that out the slow way. ## Intelligence was never the bottleneck My first year of using AI seriously inside the business, the model was rarely the problem. It could read a contract, summarize a thread, draft a reply, spot an inconsistency across two documents faster than I could. The problem showed up when I asked it to do something instead of say something. A model that drafts an email is a writer. A model that sends the email, updates a record, or moves money is an operator. Those two roles need different things from the system around the model, not from the model itself. I started keeping a list of what an operator actually needs. Not what makes a model smarter. What makes it safe to operate. ## Identity and authority The first thing an operating system asks of anything running inside it is who are you and what are you allowed to do. Every process gets an identity. Every identity carries a permission set. Nothing runs as root by default, and the things that do run as root are the things everyone watches most carefully. Most AI deployments skip this step entirely. The model is the model. It has one identity, usually the identity of whoever is holding the API key that day. It gets access as a single blunt unit, everything or nothing. That does not survive contact with a real business. An agent that can read a customer's history should not automatically be the same agent that can approve a refund. An agent that can draft a compliance memo should not automatically be the agent that can file it. Identity has to be granular enough that authority can be granular too. ## Current state, and whose meaning wins The last piece described a loop: event, state, decision, action, receipt, new event. An AI operating inside that loop needs to know where the state actually stands right now, not what it can reconstruct from the last few messages in a chat window. That sounds obvious until you watch it fail. A model with a long, well prepared prompt and no access to current state will confidently answer a question about a customer's account using information that was true two weeks ago. It will not tell you that. It has no way to know it is wrong. There is a second layer under this one, and it matters more than it looks. Even with access to current state, something has to decide what the words in that state actually mean. Is "closed" a closed ticket or a closed account. Does "pending" mean waiting on us or waiting on them. A human resolves that ambiguity by instinct, usually without noticing they did it. A model needs that meaning made explicit somewhere, or it will guess, and it will guess with total confidence. I call that semantic authority. Somebody, or something, has to own what a term means across the whole operation, or every agent invents its own dialect, and none of them can be trusted together. ## Tools, and the gap between talking and doing A model with no tools can only talk. Give it a tool and it can act, which sounds like an upgrade until you notice what actually changed. It did not become more capable of judgment. It became capable of consequence. Every real operating system draws a hard line around what a process can touch. Filesystem permissions. System calls that require a privileged mode. A kernel that mediates every request instead of trusting the process to behave. None of that exists because engineers distrust their own code. It exists because the cost of an unmediated mistake is too high to leave to good intentions. The tools an agent gets should be scoped the same way. Read access is not write access. Draft access is not send access. A tool that checks a balance is a different tool from one that moves it, even when the same model calls both. ## Memory and permissions have to travel together Memory without permission is a liability. An agent that remembers everything it has ever seen, across every context, will eventually surface something in a place it should not. A support conversation should not leak into a sales conversation just because the same model handled both. Permission without memory is close to useless. An agent that starts every session from zero cannot learn what already failed, what was already tried, what a customer already explained twice. It will ask the same question a third time, and the person on the other end will lose patience with the whole idea of AI, reasonably. The two have to be designed together. What an agent remembers, and who it is allowed to remember it for, are one design decision, not two decisions made by two different teams on two different timelines. ## Evidence is the action I said this in the last piece and it is even more true here. A model producing an answer is not the same as the business taking an action. The receipt is what closes that gap. Every real action an agent takes should leave a trail a human can read without having to trust the agent's own account of what it did. A request. A timestamp. An identity. A before and an after. If an agent cannot produce that trail, it should not have been allowed to act in the first place, regardless of how confident its output looked. I do not treat this as a compliance requirement I am tolerating. It is the only mechanism I have found that lets me extend an agent's authority over time without extending my own anxiety at the same rate. ## Rollback is a feature, not a repair Operating systems assume things will go wrong. Transactions can be rolled back. Deployments can be reverted. A bad write does not have to become a permanent fact simply because it happened. Most first attempts at giving an AI real authority skip this entirely, because the demo never fails. Production always eventually does. An agent that can act but cannot be undone is not an operator. It is a one way door, and one way doors should require a human hand on them, every time. The question I ask before granting any agent a new capability now is simple. If this turns out wrong, how do we undo it, and how fast. If the honest answer is "we can't," the capability is not ready, no matter how good the model is. ## Human gates are not a lack of trust in the model This is the part that surprised me most. Adding human gates did not slow the system down as much as I expected going in. It made me comfortable extending the system faster, because the boundary of what could go wrong stopped being the whole business and became one decision at a time. Evidence is not approval. A clean test run is not a business decision. An agent recommending an action, even correctly, is not the same as that action being authorized. The line between what a machine can prepare and what a person must approve is not a limitation on the AI. It is what makes it possible to give the AI more room next month than it has today. ## What would change my mind I do not think this list is complete, and I would be surprised if it kept exactly this shape a year from now. If I found a way to make identity, evidence and rollback cheap enough that they stopped requiring deliberate design, most of this piece would become unnecessary, and I would be glad about that. What I am not claiming is that any of this makes an AI trustworthy on its own. It does not. It makes the environment around the AI trustworthy enough that the AI's mistakes stay small, visible and reversible. That is a lower bar than "the model is right." It is also, so far, the only bar I have found that survives contact with a real operation. ![AI request, authority, state, tools, execution, evidence, receipt and human gate](https://storage.ghost.io/c/1a/9d/1a9dd23d-73cb-4af4-a073-c42a257a2cc9/content/images/2026/09/OPERATING_NOTES_diagram.png) Intelligence is not authority. This is the difference. --- Read in Portuguese: [O que uma IA precisa antes de você deixá-la operar](https://onchain-fx.ghost.io/o-que-uma-ia-precisa-antes-de-operar/) **Follow the money through Brazil. Subscribe to ONCHAIN FX Weekly.**