Draw Your AI Stack: A One-Page Architecture Map for Leaders

An AI architecture diagram for business is a single page that shows the work being done, the agents doing it, the models behind them, the tools and data they touch, and the person who owns each part. Draw it as labeled bands read from top to bottom, with arrows only where information or action actually moves, and a named owner on every box. If a leader can read it in a few minutes and say who to call when something goes wrong, it is working.

Key takeaways

• Five bands are enough: work, agents, models, tools and data, owners. Anything more belongs in an appendix.
• Every box needs a human owner by name, and every arrow needs a label saying what moves and whether it can change something.
• Mark each connection as read, draft or act. That single distinction answers most leadership questions about risk.
• Draw what exists today, not what a vendor presentation promises. Gaps and missing owners are the most useful things the map will show you.
• Treat the page as a living document with a review date, not a one-time deliverable.

Why does a leader need a one-page AI map?

Most companies adopt AI in pieces. A chat tool for the sales team, an assistant inside the helpdesk, a script someone built over a weekend that calls a model through a personal account. Each piece makes sense on its own. Together, nobody can say which systems the AI can reach, which data leaves the building, or who gets the phone call when an answer is wrong.

Technical diagrams do not solve this, because they answer engineering questions: queues, containers, protocols. A leader needs different answers. What is this for? What can it touch? Who is accountable? What happens if it stops? Those are questions about responsibility, and a single page can hold them.

The map also gives your teams a shared vocabulary. When finance, operations, legal and IT point at the same box, conversations about budget, access and risk get shorter. Frameworks such as the NIST AI Risk Management Framework begin with the idea that an organization must first map where AI is used and who is accountable for it. This page is a practical way to do that first step without a committee.

What belongs on the page?

Use five horizontal bands, labeled in plain words, stacked so that the business purpose sits at the top and accountability sits at the bottom.

• Work: the business tasks or roles the AI supports, such as answering supplier emails or preparing a weekly report. Start here, because every other band exists to serve it.
• Agents: each named agent or assistant, with one line describing its role and where people reach it (a shared inbox, a team chat, a web page).
• Models: the language model behind each agent, and whose account it runs under. If you use more than one, show which agent uses which. The article on when more than one AI model pays off explains why that choice is worth making deliberately.
• Tools and data: the systems each agent reads from or writes to, such as the CRM, the document store, the calendar or the accounting system. Include the agent's memory here, the place where it keeps what it has learned about your business.
• Owners: for each column, one named person who approves changes and one who handles problems.

Label boxes with the words your staff already use. If a label needs a glossary, rewrite it. If you want the deeper technical structure behind these bands, the seven layers of company AI infrastructure is the companion piece, but the leader's page should not reproduce it.

Some tool connections use open standards, such as the Model Context Protocol, which describes a common way for AI applications to connect to tools and data. You do not need to draw the protocol. You need to draw what is connected and what permission that connection carries.

How do you draw it, step by step?

This can be done in one working session of an hour or two, on a whiteboard or on paper. A photograph of a whiteboard is a perfectly acceptable first version.

• Step one: Write the five band names down the left side of a landscape page.
• Step two: In the work band, list each task the AI supports, one box each. Include informal use, such as a manager pasting reports into a chat tool.
• Step three: In the agents band, place one box under each piece of work. Write its role in a single sentence and name the channel people use to reach it.
• Step four: In the models band, add the model behind each agent and the account it runs under. Mark whether that account belongs to the company, to a provider or to an individual. The piece on who owns AI API keys in a business explains why that mark matters.
• Step five: In the tools and data band, add every system each agent touches. Draw arrows from the agent to the system and label each one read, draft or act. Use a dashed line for read and draft, and a solid line for act.
• Step six: Tag each system with a sensitivity level in words: public, internal or restricted.
• Step seven: In the owners band, write a person's name, not a department. Add a backup name.
• Step eight: Draw a boundary line around anything outside your company's control, such as a provider's hosted service, so readers can see where data crosses.
• Step nine: Write the date, a version label and the next review date in a corner.

Draw the map with the person who runs the operation, not alone with IT. The people who actually use the agent know about the shared login, the spreadsheet export and the habit of forwarding emails that never made it into any official description.

What does the map look like in practice?

Illustrative scenario: a regional distributor with a small operations team uses AI for two jobs. One agent drafts replies to supplier delivery questions. A second assistant helps the finance lead prepare a weekly report.

On the map, the work band has two boxes: supplier correspondence and weekly reporting. The first agent sits under supplier correspondence and is reached through a shared mailbox. Its arrows go to the mailbox (read), the order system (read) and a drafts folder (draft). Nothing is marked act, so a person sends every reply. The report assistant has one arrow to an accounting export (read) and nothing else.

Drawing this exposes three things. The report assistant runs on a model account registered to the finance lead's personal email. The order system connection uses an administrator login shared by the whole operations team. And nobody is named as owner of the supplier agent's memory, which has been collecting notes about suppliers for months.

None of these is a technology failure. Each is a gap in ownership, and each is closed with a decision rather than new software: move the account to the company, give the agent its own restricted login (the reasoning is in why your company AI agent needs its own identity and accounts), and name an owner for the memory.

How do you read the map once it is drawn?

Use the page as a review tool. Walk through it with the owners in the room and ask these questions in order.

• Which arrows are marked act, and who approved each one? Connections that change things deserve the most scrutiny. Authorization guidance such as the OWASP Authorization Cheat Sheet recommends giving each identity only the access it needs, and the map shows you where that has not happened.
• Does any box have no owner, or an owner who has left the company?
• Where does restricted data cross the boundary line, and was that a deliberate decision?
• Which accounts belong to the company, and which belong to a person or a provider?
• If one model or provider became unavailable next month, which boxes would stop working, and what is the fallback?
• Where is activity recorded, and who looks at it? An agent with no visible record of its work cannot be reviewed.

One combination deserves a second look. If an agent reads content from outside the company (incoming email, web pages, uploaded files) and also holds an act arrow, someone could try to hide instructions in that content to steer the agent. The OWASP guidance on prompt injection prevention describes this class of risk. On the map it shows up simply as an untrusted read arrow sitting next to an act arrow, which is easy to spot and usually easy to fix by requiring human approval before the action.

What mistakes make the map useless?

Most failed maps fail for the same few reasons.

• Drawing vendor logos instead of roles. A page of product names tells you what you bought, not what the AI is responsible for.
• Showing everything. If the page needs small print, split it: keep the leader's view to the roles that touch company data or take action, and list the rest in a short note underneath.
• Putting departments in the owners band. A department cannot approve a change or answer a call. A short RACI for company AI agents turns the names on the map into clear duties.
• Leaving out informal use. Personal accounts and pasted documents are usually where the real exposure sits.
• Drawing it once and filing it. A map that is a year old describes a company that no longer exists. Put the review date on the page and keep to it.

How does a managed approach keep the map accurate?

Be Human designs, implements and operates personalized AI infrastructure, and the five bands mirror how a first engagement is scoped: one useful role, the memory and tools it needs, approval boundaries and an observable success criterion. During managed operations, monitoring, permission review and integration maintenance are the points where the map would otherwise drift, so a change to a tool, model or permission is recorded and tied to a named approver. The company keeps control of its agents' identity, memory and permissions, and the work is done remotely in English and Portuguese.

Frequently asked questions

Do I need a technical person to draw the map? You need one in the room, but not holding the pen. A leader who knows the operation and someone who knows which systems are connected can complete the first version together in a single session. The test is whether a colleague outside both groups can read it without help.

Should the map include AI features built into software we already use? Include them if they handle company data or can take action, such as an assistant that sends messages from your email system. Features that only suggest wording inside a document can be listed in a short note under the map. Add them to the main page if their access grows.

How detailed should the data band be? Name the system and its sensitivity level, and stop there. You do not need table names or field lists. The goal is to see which restricted systems an agent can reach and whether the connection is read, draft or act.

How is this different from a standard architecture diagram? A standard diagram shows how components connect so engineers can build and fix them. This page shows what the AI is for, what it can touch and who is accountable, so leaders can decide and act. The two should agree, but they answer different questions, and the leader's page should stay readable without technical background.

Be Human editorial guidance. Examples are illustrative unless explicitly attributed. Sources provide background; implementation choices depend on your workflow.