AI Infrastructure Roadmap for Companies: A First-Year Plan

A workable AI infrastructure roadmap for companies runs in four quarters. Define and build one role, prove it with real users, harden the operations around it, then review everything before deciding what to add. Each quarter ends with a decision rather than a deliverable, so the plan can continue, pause or change direction based on evidence.

Key takeaways

• Start with one role, not a platform. The first quarter defines what the agent does, what it knows, which tools it touches and who approves its actions.
• Treat each quarter as a gate. You move on only when the previous quarter produced an observable result you can inspect.
• Operations are part of the build. Monitoring, permission review, backups and evaluation routines belong in the plan from the beginning, not after launch.
• Widen scope slowly. A second role or a new channel is a decision for the final quarter, taken with evidence from the first role.
• Nothing in a roadmap guarantees an outcome. What it gives you is a sequence in which every step can be checked, adjusted or stopped.

Why plan AI infrastructure by quarter instead of by tool?

Most stalled AI efforts begin with a tool purchase and end with an argument about what the tool was for. A quarterly sequence reverses this. You decide the job first, then the memory and access that job requires, then how the work will be observed and reviewed.

Quarters work because they match how companies already make decisions: budgets, leadership reviews and staffing changes happen on that rhythm. A plan measured in quarters fits into those conversations. A plan measured in features does not.

There is a second reason. AI infrastructure has several layers, from the model and its identity to memory, tools, permissions and operations. If you try to settle all of them at once, you decide most of them badly. The seven layers of company AI infrastructure are a useful map, but a map is not a schedule. The roadmap below decides which layer receives attention first, and why.

One caution before the sequence. The quarters below are a pattern, not a promise. A company with strict procurement may spend its first quarter on access and contracts. A company with a clear process and an engaged team may move faster. The order matters more than the calendar.

First quarter: what does one useful role need?

The first quarter has a narrow purpose: describe a single role well enough that someone could build it, test it and be held accountable for it. Resist the temptation to define five roles. One role, written clearly, teaches you more than a broad ambition.

A good first role is a recurring piece of work with a visible owner, a bounded set of inputs and a result someone can check. Preparing weekly account summaries, triaging an internal request inbox or drafting first-pass replies to common supplier questions are typical shapes. If you need help choosing, a four-factor scoring method or a short team workshop can narrow the field quickly.

Write the role down as you would for a new hire. A job description for your first AI agent should cover:

• The purpose of the role in one sentence.
• The inputs it receives and the outputs it produces.
• The memory it needs: documents, policies, past decisions, glossaries.
• The tools it may use, and for each tool, whether it can read, draft or act.
• The actions that always require human approval.
• The person who owns the role and the person who reviews its work.

Then settle the foundations that are cheap now and expensive later. Give the agent its own identity and accounts, separate from any employee. Decide who holds the model accounts and API keys. Decide where company data will be stored and processed. Read what the provider says about training on your data and get the answer in writing. None of this is glamorous, and all of it is difficult to retrofit.

The end-of-quarter gate is simple. Can you hand the role description to a stranger and have them explain back what the agent does, what it may touch and who approves what? If not, the quarter is not finished.

Second quarter: how do you prove the role with real users?

The second quarter moves from description to evidence. You build the role with the memory and tools you defined, give it to a small group, and measure it against a criterion you wrote down before anyone used it.

The criterion matters more than the technology. Choose something observable: the time a task takes, the share of drafts accepted without major edits, the number of requests handled without escalation. Do not pick a number you cannot measure today. If you have no baseline, the first weeks of the pilot can establish one. The article on defining success criteria for a pilot goes through this step in detail.

Choose pilot users who will give honest feedback, not those who are merely enthusiastic. A small group with different working styles will expose problems faster than a large group with the same habits. Teach them what the agent is for, what it cannot do and how to report a bad result before the first day.

An illustrative scenario: a distribution company defines a role that prepares weekly summaries of open customer orders for its account managers. The agent reads from the order system and a shared policy document, drafts the summary and never sends anything on its own. In the pilot, three account managers use the drafts for a few weeks, flag errors in a shared log and record how much they edit. At the end of the quarter, the owner compares the log with the criterion written at the start and decides whether to continue, change the role or stop. The scenario is invented, but the shape is the point: small group, written criterion, logged problems, a decision.

During this quarter, keep the agent's permissions as narrow as the role allows. Read access first. Drafting before acting. Approval before anything leaves the building. If the role needs wider access, expand it deliberately and record why.

The gate for the quarter: you have a log of real use, a comparison against your criterion and a clear recommendation. Continue, adjust or stop are all acceptable outcomes. A pilot that cannot end in "stop" is not a pilot.

Third quarter: what has to be in place before the agent becomes routine?

If the pilot met its criterion, the third quarter is about turning a working experiment into something the company can depend on. The distinction is operational. A pilot survives on attention. A routine service survives on process.

Treat this quarter as a checklist of operating basics:

• Observability. You can see what the agent did, which tools it called, what it cost to run and where it failed. Basic concepts of traces, logs and metrics apply here as they do to any software system.
• Evaluation. A fixed set of representative tasks that you rerun after every meaningful change, so you can tell improvement from regression.
• Permissions. A first permission review comparing what the agent can reach with what the role actually needs.
• Backup and restore. A saved copy of memory, configuration and role definition, and a rehearsed restore.
• Change control. A written way to update prompts, tools and knowledge without breaking the live role.
• Incident handling. A named person, a way to pause the agent and a short record of what happened.

This is also the quarter to settle adoption. Early users know the agent. Their colleagues do not. Plan short training, a clear channel for feedback and a visible owner. If people do not trust the agent or do not know when to use it, the infrastructure will be correct and idle.

Security deserves explicit attention here. Agents that read external content can be steered by instructions hidden in it, and agents with tools can be given more authority than anyone intended. Reviewing authorization and prompt injection exposure against recognized guidance is a reasonable routine, not a one-off.

The gate: if the person who built the role were unavailable for a week, would the company still know how to run, pause and restore it? If the answer is no, the quarter needs more time before anything else is added.

Fourth quarter: what does a reviewed operation look like?

The final quarter is a review, followed by a decision about the second year. By now you have several months of real use, a log of incidents and changes, and an evaluation set that tells you how the role has behaved.

Run the review in four parts:

1. Outcome. Did the role meet the criterion you set, and does it still? Use the evaluation set and the usage record, not impressions. 2. Access. Repeat the permission review. Remove anything unused. Confirm that every credential, account and integration has a named owner. 3. Cost and effort. Count what the role actually required: model usage, integration upkeep, review time and human attention. A role that works but costs more effort than it saves is a finding, not a failure. 4. Risk. Review incidents, near misses and open questions against whatever governance approach you have chosen. A lightweight framework is enough for most mid-sized companies.

Only then decide what comes next. There are four honest options. Keep the role as it is. Improve it. Add a second role, using the same process from the first quarter. Or retire it. Adding a second role is a stronger decision after a clean review, because you are reusing proven foundations: identity, memory practices, permission routines and evaluation habits.

Two questions that often surface in this quarter are whether to run one agent for the whole company or one per team, and whether to depend on a single model provider. Both are easier to answer with a year of evidence than with a forecast. Whatever you decide, keep your role definitions, memory and configuration in formats you own, so a change of provider remains possible.

How does Be Human's managed approach fit this sequence?

Be Human designs, implements and operates personalized AI infrastructure for companies, with the agent's identity, memory, channels, tools and permissions under human control. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion, which corresponds to the first two quarters above. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements, which covers the third and fourth. The work is remote, in English and Portuguese, and the company keeps the decisions: what the role is, what it may do and when it grows.

A short checklist to test your own roadmap

Before committing to any plan, yours or a vendor's, check it against these questions:

• Does the first quarter end with one written role, not a platform?
• Is the success criterion written before the pilot begins?
• Is there a named owner and a named reviewer for the role?
• Does the plan include monitoring, permission review and restore testing, with an owner for each?
• Can the pilot end in a decision to stop?
• Are the role definition, memory and configuration stored where the company can retrieve them?
• Does the final quarter include a review before any expansion?

A plan that answers yes to all seven is not guaranteed to succeed, but it is checkable, and that is what a roadmap is for.

Frequently asked questions

How long should each phase of an AI infrastructure roadmap take? The quarters here are a planning rhythm, not a rule. Some companies need a full quarter for access, contracts and data questions alone, while others move through the role definition in a few weeks. Let the gate at the end of each phase, not the calendar, decide when to move on.

Do we need an internal technical team to follow this roadmap? Not necessarily, but you do need people who own decisions: the role, its approvals and its review. Technical work such as integrations, monitoring and maintenance can be handled by an external partner, as long as the company keeps access to its own accounts, data and configuration.

Should we start with several departments at once? It is usually better not to. One role teaches you how identity, memory, permissions and evaluation work in your environment, and those lessons carry over to the next role. Starting everywhere at once multiplies the number of unknowns and makes it hard to tell what is working.

What if the first role does not meet its criterion? That is a legitimate result, and the roadmap is built to surface it early and cheaply. Review the log to see whether the problem was the role, the memory, the tools or the criterion itself, then adjust, narrow or stop. Learning that a role does not fit is far better than discovering it after a wide rollout.

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