AI architecture: strategy, operating model and controls
AI architecture is the design of how artificial intelligence and superintelligence run inside an organization: the operating model, the systems, and the controls. Strategy that ends in a design names where the systems are used, who holds each decision, and how control is shown to a board or a regulator.
AI strategy that ends in a design
An AI strategy that cannot be handed to the people who run the work is a speech. AI architecture is the design that follows a real question: where artificial intelligence and superintelligence will be used, what they are allowed to do there, and what has to be true before they do it. We are hired as an AI strategy consultant when leadership already knows the topic matters and is tired of documents that do not decide anything.
The design starts from the audit when there is one, and from a short audit when the organization wants to go straight to architecture. Guessing the operating model from a vendor roadmap is how organizations end up with a system that decides more than anyone agreed. We would rather spend the first part of the work on the decisions than on the tools.
Strategy, in this practice, is a set of choices. Which decisions stay with people. Which a system may recommend. Which a system may take, and under what stop rule. Which uses are refused for now. An operating model consulting engagement that will not make those choices is not strategy. It is a tour.
Operating model
The operating model is who does what once the system is in the work. It names the owner of each use, the forum that hears exceptions, and the difference between a recommendation and a decision. A recommendation that nobody is allowed to overrule is a decision. The design says so, instead of hiding it in a workflow.
We write the model against the organization you have, not against a chart from another company. A private company, a public company, a government agency, and a non-profit do not share a forum, a record, or a duty. The model has to survive contact with those duties. If a sector rule says a named role must make a call, the design does not quietly move that call to a system.
The model also says what happens on a bad day. The system is wrong. The system is down. The vendor changes the behavior. The person who understood the use has left. If the design has no answer for those four, it is a fair-weather diagram. We treat them as part of the operating model, not as an appendix.
Systems and data architecture
Systems and data are in scope because a control that ignores them is fiction. We set what is connected, what is kept apart, and what record is retained of what the system saw and what it produced. We do not draw a platform for its own sake. A box on a diagram earns its place only if a decision depends on it.
Data questions are specific. Which records are allowed into the use. Which must never be. How long a prompt, a file, or an output is kept, and who can see it later. Whether a vendor's retention becomes your retention problem. Whether a use trained or tuned on your information can be explained to the person the information is about. If those answers are unknown, the design says unknown, and the use does not proceed as if they were settled.
We do not implement the systems. Architecture here is the design and the decisions, not a build crew and not a reseller arrangement. If you need engineers to carry out an accepted design, that is a different hire, and we will say so. Mixing the two is how the design starts to serve the build.
Controls built in
Controls are part of the design, not a review after go-live. Each use that the design allows has a named owner, a way to stop it, and a record of what it did that a board or a regulator could read without a translator. A control that lives only in a policy, while the system has no stop, is not a control.
We also design the refusal. Some uses should not be architected yet, because the data is wrong, the obligation is unclear, or the organization cannot explain the decision. Leaving those uses out is a result. An AI implementation consultant who treats every request as a thing to be built is not doing this work.
Superintelligence changes the control problem because the system can take on judgment, not only a task. The design has to say, in advance, which judgments remain human even when the system is capable of them. Capability is not permission. That sentence belongs in the operating model, not in a values poster.
Before a design can be used
A design without a current picture of the uses is a guess. If a written position already exists and we can rely on it, we start there. If it does not, the review comes first and the design follows what it found. Carrying an accepted design into the organization, with named owners and controls in place, is retained counsel, not a later phase we invent. The engagement page is where that account lives.
You receive a decision and control design: where superintelligence is used, who holds each decision, how each use is secured, and the record you would show. You do not receive a tool catalog or a promise that the design cannot fail. Request a briefing if the question is the operating model, not a product selection.
Related reading: the AI audit if you do not yet know where the systems sit, AI advisory if leadership needs ongoing counsel after the design, and AI governance consulting if the gap is oversight rather than the model of the work.
Questions about the design
What is AI architecture in this practice?
It is the design of how artificial intelligence and superintelligence run inside the organization: the operating model, the systems and data, and the controls. It is the form an AI strategy takes when it has to be used, not only presented.
What is an AI operating model?
It names who owns each use, which decisions a system may recommend, which it may take, who hears exceptions, and what happens when the system is wrong, down, or changed. A recommendation nobody can overrule is treated as a decision.
Do you build the systems?
No. We design the decisions and the controls. We do not implement software and we do not resell a platform. If a build is required after the design is accepted, that is a different hire, and we will say so.
What do we receive?
A decision and control design. It states where the systems are used, who holds each decision, how each use is secured, and the record you would show a board or a regulator. It also states which uses are refused for now.
Do we need an audit first?
Usually, yes. A design that skips the question of where systems already sit will guess. If you already have a current written position, we can start closer to the design. That is settled at the briefing, not assumed.
Who is this for?
Private, public, government, and non-profit organizations in the United States whose leaders need the operating model decided. It is for the people who will have to run the design, not for a tools evaluation.
Other services
When the strategy has to run
Tell us whether you need an operating model, or a design that follows a review you already trust. We answer at your work email.
Request a briefing