Topic
Enterprise AI Systems: Architecture & Controls
Enterprise AI is an architecture problem long before it is a model problem. The interesting questions are where an agent sits relative to the systems of record, what it is allowed to write, which decisions it may take alone, how its work is logged and reviewed, and what happens on the day it is wrong.
This hub covers that layer: integration with the systems the business already runs on, enterprise data and state, controls and segregation of duties, human oversight boundaries, and the observability without which none of it can be trusted in production. Grounded in a career spent integrating systems that were not designed to talk to each other.
16 articles · ~120 min, in 4 sections — each in reading order
Architecture
6 articles · ~50 minWhy Enterprise AI Is an Architecture Problem
Enterprise AI stalls on architecture, not model quality: who owns the record, what the AI may write, under whose identity, and how it is logged and rolled back.
How AI Agents Fit Into Existing Enterprise Systems
The four placements an AI agent can take beside your existing systems — read-only, propose-and-queue, scoped write, orchestrator — and what each one demands.
Should You Connect an AI Agent Directly to Your ERP?
Practitioners say don't, vendors say it's supported. They answer different questions. Three things a direct connection costs — one of them commercial.
The Enterprise AI Control Layer
You cannot make an AI system safe by improving the model. Safety lives in a control layer between your systems of record and the agents acting on them.
AI Agents in SAP: What Actually Lands in the System
Role-aware is not segregation-safe. What an agent posting in S/4HANA leaves on the document, in the release path, and in front of the auditor at period end.
Agent Identity: Who Is the AI Acting As?
Delegated, shared, agent-specific or temporary — the four identities an AI agent can act under, and what each one costs you in attribution and blast radius.
Security
4 articles · ~30 minSecurity Boundaries for Enterprise AI Agents
An agent that reads untrusted content can be instructed by it. What the boundaries are, which of them hold under pressure, and which are theatre.
Four-Eyes and Segregation of Duties for AI Agents
A human clicking approve on an agent's proposal is not a second pair of eyes. What independence requires when one of the two parties is a model.
Can an AI Agent Approve Its Own Payment?
It is not a new question. It is a release strategy — and the per-transaction limit everyone reaches for is the one an agent defeats first.
The OWASP LLM Top 10 (2026), Read From a Finance Seat
All ten 2026 entries with what changed from 2025 — and which of them a finance or treasury deployment actually meets first.
Engineering
4 articles · ~24 minAI Output Contracts and Failure Handling
A model will return the wrong shape, or a confident lie. How to design output contracts, validation and fallbacks so an enterprise process fails safely.
Enterprise AI Evaluation & Regression Testing
How to build eval sets for AI running inside an enterprise — cases, scoring, a regression gate — so a prompt or model change is judged on evidence, not vibes.
Production AI Observability in the Enterprise
You can't fix what you can't see. How to observe AI running inside an enterprise — quality, cost, latency, drift and failures — as data, not complaints.
Prompt & Model Versioning: Enterprise AI Governance
A prompt is production code and a model is a dependency you don't control. How to version prompts, handle model changes and stop silent regressions.
Governance
2 articles · ~16 minThe EU AI Act's High-Risk Rules Are a Control Environment
The high-risk deadline moved to December 2027. What the rules ask for did not move — and a finance function already runs most of it under other names.
NIST AI RMF: The Functions and Categories, Explained
All four functions and 19 categories of the NIST AI Risk Management Framework, with subcategory counts — and which finance controls already cover each one.
Frequently asked questions
Why is enterprise AI an architecture problem rather than a model problem?
Because the model is the most replaceable component in the design and everything around it is not. Model quality decides whether a demo impresses; architecture decides whether the capability can run against systems that already hold the company's money, contracts and master data. The questions that actually gate a rollout are which system owns the data, what the AI is permitted to write and under whose identity, how its actions are logged and reconciled, how it behaves when a system it depends on is unavailable, and how a bad change is rolled back. None of those are answered by choosing a better model.
Full article →Where should an AI agent sit relative to the systems of record?
Alongside them, at the lowest placement that still delivers the value. There are four practical positions: read-only beside the systems, producing analysis a human acts on; propose-and-queue, where the agent drafts an action and a named person approves it; write-through under a narrowly scoped identity for a defined class of low-consequence actions; and orchestrator, coordinating steps across several systems. Each step up multiplies both the value and the blast radius, so the placement should be an explicit design decision with named criteria for moving up — never something a capability drifts into because it was already connected.
Full article →What is an enterprise AI control layer?
An enterprise AI control layer is the component that sits between the AI or agent layer and the systems that hold the company's state, and decides whether anything the AI produces is allowed to become an action. It owns identity, permissions, the deterministic rules and thresholds that must not be re-derived probabilistically, policy, approval requirements, segregation of duties, output validation, limits on how much may be done in a window, logging, a stop control, and the route for anything it cannot handle. Almost every enterprise already has this layer around its ERP postings and payment releases. AI does not get an exemption from it.
Full article →Should an AI agent use the user's identity or its own?
Whether an agent acts under the user's identity or its own depends on which property you need most. Acting under the requesting user's delegated identity is honest about who wanted the work and inherits their limits automatically, but the trail then shows a person doing things at a volume and hour no person did, and revoking the agent means touching the person. An identity of its own attributes cleanly, can be scoped to exactly its job, and can be switched off without disturbing anyone — at the cost of a standing set of rights that exists whether or not anyone is asking. Many designs need both: the agent's own identity, bounded by the requesting user's.
Full article →Can prompt injection be prevented in an enterprise agent?
Prompt injection cannot be prevented reliably, and a design that depends on preventing it is the design to worry about. Instruction and data arrive through the same channel, so a model has no dependable way to tell a supplier's invoice text from a command. What you can do is make a successful injection uninteresting: give the agent an identity that can only reach what this task needs, route every consequential action through something that is not a language model, and require a human for anything irreversible. Treat injection as certain and design for the blast radius, the same way payment controls assume someone will eventually try.
Full article →Work with me → — an opportunity scan, a redesign sprint, or an architecture review before AI meets your real landscape.