Skip to content
be-human.ai
← Back to the journal

Personalized AI infrastructure

AI Maturity Model for Companies: Five Practical Stages

A practical AI maturity model for companies: five stages from scattered chat use to managed agents, with observable signs to show where you stand today.

Five stacked stones of travertine, green marble, glass, ceramic and ivory paper on an oak table in warm sunlight beside a folded linen cloth.
Conceptual illustration created with AI · Be Human

An AI maturity model for companies describes how reliably and safely AI does useful work inside the business. It runs from individuals using chat tools on their own to agents that have a defined role, limited access and scheduled review. This article uses five stages and gives observable signs for each, so you can place your company by checking facts instead of guessing.

Key takeaways

  • Maturity is not how much AI you use. It is how clearly you can answer four questions: who owns it, what it remembers, what it can touch and how you know it works.
  • The five stages are scattered use, shared practice, a defined agent role, a connected and governed setup, and managed operations.
  • Each stage has signs you can verify this week, such as whether an agent has its own account or whether someone reviews its permissions on a schedule.
  • Skipping a stage usually shows up later as an agent nobody trusts, so move one stage at a time and attach each move to an observable result.
  • Stage five is not right for everyone. Many teams are well served at stage two or three, as long as they know that is where they are.

What should an AI maturity model for companies actually measure?

Many maturity models score enthusiasm: how many people have tried a tool, how many licenses are active, how many pilots exist. Those numbers say little about whether the company can rely on the work. A more useful model measures the conditions around the AI, not the volume of its use.

Four questions carry most of the weight:

  • Ownership: is there a named person or team accountable for what the AI does and for changing it?
  • Context: what does the AI know about your company, where is that knowledge stored, and who keeps it current?
  • Access: which systems can it read, draft in or act on, and under whose identity?
  • Evidence: how do you know it is doing the job well, and how quickly would you notice if it stopped?

These questions line up with the broader risk practice described in the [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework), which organizes the work into governing, mapping, measuring and managing. You do not need the whole framework to use the idea. You need to see that maturity grows when each question has a clear, written answer.

One caution before the stages. Higher is not automatically better. A five-person team that uses a chat assistant for drafting, with clear rules, may be exactly where it should be. The model is a map, not a ranking.

Stages one and two: from scattered chat use to shared practice

Stage one is scattered use. People use whatever chat tool they prefer, often on personal accounts. Some get real value from it, but the value lives in individual habits. The company cannot repeat it, review it or protect it.

Observable signs of stage one:

  • Nobody can list which AI tools are in use across the company.
  • Company documents, customer messages or contracts are pasted into personal accounts.
  • Two people asking the same question get different quality because they prompt differently.
  • If a heavy user leaves, their techniques leave with them.
  • There is no written rule about what may or may not be shared with an AI tool.

Stage two is shared practice. The company has chosen approved tools, written a short usage policy and collected prompts or templates that work. Training exists, even if informal. The human is still the only integration: someone copies information into the chat and copies the answer out.

Observable signs of stage two:

  • A one-page usage policy exists and people can find it.
  • There is a shared folder or document of prompts that others reuse.
  • Company accounts, not personal ones, are used for approved tools.
  • The assistant forgets everything between sessions, so context is re-pasted each time.
  • Quality still depends heavily on who is asking.

The jump from one to two is mostly organizational, not technical. It costs attention, not infrastructure. It is also where team adoption is won or lost, because people follow rules they helped shape and ignore rules that arrive from nowhere.

The limit of stage two is structural. A chat window has no durable memory of your business, no tools and no identity of its own. You can polish the prompts forever and still hit that ceiling.

Stages three and four: from one defined role to a connected, governed setup

Stage three begins when the company stops asking what the AI can do in general and starts asking what one specific role it should hold. The agent has a job description, a bounded memory, a small set of tools and approval points where a person confirms before anything leaves the building. Writing that down is the real milestone, and a job description for your first AI agent role is a good way to do it.

Observable signs of stage three:

  • You can describe the agent's role in one page, including what it must not do.
  • It has its own account and identity, separate from any employee.
  • Its access is limited to what the role needs, with read, draft and send treated as separate permissions.
  • A person approves anything irreversible or external, such as sending a message to a customer.
  • There is one success criterion someone can observe, for example the share of incoming requests correctly routed, reviewed on a sample.
  • Memory is stored somewhere the company controls and can inspect.

Stage four is the connected and governed setup. The agent works across more than one system or channel, or there are several roles, and the company has built the surrounding discipline: logs, owners, change control and review. The question shifts from whether it works to whether it keeps working safely as things change.

Observable signs of stage four:

  • Actions are logged well enough to reconstruct what happened and why.
  • Someone is named as owner, and there is a known path for requesting changes.
  • Changes to instructions, tools or models are tested before they reach live use.
  • Permissions are reviewed at a set interval, not only when something breaks.
  • Connections that expire or fail produce a defined behavior, not silent errors.
  • A lightweight governance routine exists. For mid-sized firms, AI governance for companies can start small and still be real.

Authorization deserves particular attention at this stage. The [OWASP authorization guidance](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) stresses least privilege and checking permissions on every request, which applies directly to an agent that holds credentials on your behalf.

The common failure between stages three and four is the pilot that works, then stalls because nobody planned for operation. The agent is useful, but its upkeep belongs to no one.

A five-compartment seed tray on an oak bench in which the plants grow taller from left to right, with a brass trowel and linen cloth beside it.
Conceptual illustration created with AI · Be Human

Stage five: what changes when agents are managed?

Stage five is managed operations. The agent is no longer a project that was delivered, it is a service that is run. Someone watches it, tests it on a schedule, maintains its integrations, reviews its permissions and improves it in controlled steps. The shift is from building to operating.

Observable signs of stage five:

  • Monitoring tells you about a problem before a user does.
  • Evaluations run on a recurring basis against realistic cases, not only once before launch. The Anthropic piece on [demystifying evals for AI agents](https://www.anthropic.com/engineering/demystifying-evals-for-ai-agents) explains why agents need this kind of repeated testing.
  • Integration changes, such as an expired connection or an updated external system, are handled as routine maintenance.
  • Incidents have a defined response, a record and a follow-up change.
  • Improvements are small, tested and reversible.
  • The company can export its instructions, memory and configuration if it ever needs to change providers.

This is not about more autonomy. The [Anthropic guidance on building effective agents](https://www.anthropic.com/engineering/building-effective-agents) recommends starting with the simplest solution that works and adding complexity only when it clearly helps. Mature operations often mean a narrower, better-supervised agent, not a broader one.

How Be Human handles this stage: Be Human designs, implements and operates personalized AI infrastructure for companies. A first engagement defines one useful role, the memory and tools it needs, the approval boundaries and an observable success criterion. Managed operations can then include monitoring, recurring evaluations, integration maintenance, permission review, incident response and controlled improvements. Service is remote, in English and Portuguese, and the company keeps control of the agent's identity, memory and permissions. For a fuller list of the recurring work, see what managed AI services include.

How do you tell where you stand? A diagnostic checklist

Use the questions below as a quick audit. Answer from evidence, such as a document you can open or a setting you can show, not from intention. Your stage is the highest one where you can answer yes to nearly all of its questions and to all of the questions before it.

Stage two questions:

  • Do we have a written AI usage policy that staff can find?
  • Do we use company-managed accounts for approved tools?
  • Is there a shared set of prompts or templates?

Stage three questions:

  • Can we describe one agent role in a page, including its limits?
  • Does the agent have its own identity and accounts?
  • Are read, draft and send permissions granted separately?
  • Do we have a success criterion that someone checks?

Stage four questions:

  • Can we reconstruct what the agent did last week from logs?
  • Is there a named owner and a change process?
  • Do we review permissions on a schedule?
  • Do we know what the agent does when a connection fails?

Stage five questions:

  • Does monitoring alert us before users complain?
  • Do recurring evaluations run, and does someone read the results?
  • Is there a response routine for incidents?
  • Could we export our instructions, memory and configuration if needed?

If you answered no to a stage-three question while believing you were at stage four, that is the useful finding. Gaps below your assumed stage are where trouble tends to start, because everything above rests on them. If your success criterion is the weak point, defining success criteria for an AI agent pilot is the place to begin.

How do you move up one stage without overreaching?

Here is an illustrative scenario, not a real case. A regional services company has six office staff who all use chat assistants on personal accounts to draft customer emails. The company is at stage one. A manager worries about customer data in personal accounts and about inconsistent replies.

The company writes a one-page policy, moves everyone to company accounts and collects the five reply templates that work best. That is stage two, reached through decisions rather than software. A few weeks later the manager notices the team still re-pastes the same service terms and customer history into every chat. That repeated effort points to the next step: one agent role, triaging incoming requests, with access to the service terms, read-only access to the request inbox, and drafts that a person approves. That is stage three.

The pattern generalizes into a short plan:

  • Name your current stage using the checklist, and write down the evidence for each answer.
  • Pick the single gap that most limits trust, not the one that sounds most advanced.
  • Define the smallest change that closes it, with an owner and an observable result.
  • Run the change on a narrow scope and review the result against the criterion you set.
  • Only then decide whether to widen the scope or move to the next stage.
  • Write down who will maintain what you built, before you build the next thing.

The last step is the one most often skipped. A stage-three agent without a maintenance plan decays quietly, and the company drifts back toward stage two without noticing. Whether the maintenance sits with an internal team or an external partner is a separate decision, but it has to be made before the agent goes live, not after the first failure.

Frequently asked questions

Do we have to pass through every stage in order? In practice, yes, though some stages can be short. Each stage builds a habit the next one relies on: policy before roles, roles before governance, governance before managed operations. Companies that jump straight to a connected agent usually end up retrofitting the earlier stages under pressure.

Is stage five the right goal for a small company? Not always. Stage five makes sense when an agent carries work the business depends on and a failure would be costly or visible. A small team with a handful of low-risk uses may be well served by stage two or three, provided it knows where it stands and has a reason to stay.

How is this different from a vendor's maturity scorecard? A vendor scorecard often measures how many of the vendor's products you use. The signs in this article are vendor-neutral: ownership, context, access and evidence. You can check each one without buying anything, and the answers stay valid if you change tools.

How often should we reassess our stage? Reassess when something material changes, such as a new agent role, a new system connection, a change of provider or a staff change that affects ownership. Otherwise a review at a regular interval is enough. The point is to keep the evidence current, so your stage reflects what is actually running.

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

Less busywork. More room for you.

Bring us the work you wish you had time for.

Try a personalized AI agent free for 7 days on WhatsApp ↗