Almost every mid-sized and large company in Brazil has already run its enterprise AI pilot. An assistant in the service desk, a contract summariser, a copilot for the data team. The demo impresses, the sponsor applauds and, three months later, the project has stalled. Not because the model was poor — models are excellent and keep improving on their own. It stalled because nobody designed the architecture around it.

In practice, the model is the cheapest and most replaceable piece of the set. The expensive part is everything else: where the context comes from, who can see what, what the AI is allowed to do unsupervised, and how you prove it paid off. So in this article we treat AI as a problem of engineering and governance — and we use Inove’s own operation as a case study.

Why AI pilots never reach production

When we open up a stalled pilot, the diagnosis usually lands on three causes — and it is rarely the quality of the model.

Poor context. The assistant answers well about the world and badly about your company. It lacks the customer history, the contract in force, last week’s ticket, the tax rule that only exists in an annex. Without that material, the AI is a brilliant intern on day one: quick, polite and uninformed.

No clear owner. The pilot is born in a business area, runs on a SaaS billed to somebody’s card and never enters the IT lifecycle. Nobody owns access, updates or incidents. When the enthusiast changes teams, the project dies of natural causes.

Unmeasured ROI. Nobody measured the baseline beforehand. How many minutes did a ticket take? How much rework per month? Without that earlier figure, any gain becomes opinion — and opinion does not survive next quarter’s budget cut.

The layers: structured, unstructured and living memory

Context is not one single bucket. It has three layers, with different costs, risks and refresh cycles. Treating them all the same is the commonest mistake.

Structured data is what already lives in the ERP, the CRM, the database, the ticketing tool. It is reliable, versioned and has an owner. The AI should not “learn” this data: it should query it in the moment, through a parameterised query, and cite the source. The right pattern here is a tool, not text.

Unstructured data is the company’s real archive: proposals, minutes, e-mails, project documentation, kickoff decks, technical reports. It holds the knowledge nobody ever typed into a form field — and it is also where the risk of leakage and of out-of-date information lives.

Living memory is the layer almost everyone forgets. It is the curated summary of what matters about a customer, an environment, a project: decisions taken, known constraints, preferences, open items. It is not the whole document; it is the distilled record. It needs a date, a source and an expiry — memory without a shelf life ages and then lies with confidence.

RAG, MCP and agents: when to use each

There are three architecture patterns, and they solve different problems. Choosing the wrong one is what produces that expensive assistant nobody uses.

RAG (search before answering). The AI looks for relevant passages in your archive and answers citing the source. Use it when the question is about static knowledge: internal policy, documentation, project history, process manuals. It is the cheapest pattern and the easiest to audit, because every answer points to a document. Do not use RAG for figures that change by the hour — balances, stock levels, ticket status. In those cases it hands you yesterday’s snapshot wearing today’s face.

MCP (the AI uses your tools). Here you do not copy data into the AI: you expose a standardised door for it to query the system in real time, with the right credential. This is the pattern for live data and for operations — raising a ticket, checking an environment’s status, reading an indicator. The governance advantage is considerable: access still belongs to the source system, with the same permission controls that already exist, rather than to a parallel copy nobody ever revokes.

Agents with guard-rails. An agent chains steps together: it queries, decides, executes, verifies. It only makes sense when the process is repetitive, has a clear rule and an error cost you can contain. And “contain” has a technical meaning: minimum credential scope, a separate environment, human approval for any irreversible step, and a complete log of every action. Without that, you have automated the mistake — which is precisely what good cybersecurity practice tells you to avoid.

Governance and data protection: personalisation without intrusion

Personalising service with AI is legitimate. What separates personalisation from intrusion is three decisions written down before the first line of code.

Purpose. Every piece of data in the context has to answer “what for”. A technical record of an environment serves to support that environment better — not to profile people. If you cannot write the purpose in one sentence, that data does not go in.

Retention. Memory with no deadline becomes a liability. Define how long each type of record lives and what happens when the contract ends. It is the same disposal discipline we apply in data volume management: keeping everything forever is expensive and it is a risk.

What never enters the context. Credentials, API keys, sensitive personal data, third-party information without a legal basis. That list has to be explicit and enforced by an automatic filter, not by the goodwill of whoever writes the prompt. Add the usual basics: role-based access, a record of who queried what, and periodic permission reviews.

Inove’s own case

We apply this to our own service operation, and the design has four stages.

First, capture: everything that happens in a support engagement becomes a record — ticket, diagnosis, technical decision, environment documentation. Then memory: instead of stacking up transcripts, we distil records per customer and per environment, with source and date. Next, context: when a consultant opens a subject, the relevant material is assembled on the spot, filtered by that person’s permissions. Finally, assisted action: the AI prepares the draft report, suggests the likely root cause, builds the verification script — and a specialist approves before anything touches the customer’s environment.

The gain is not magic, it is cumulative. The consultant who picks up a ticket at two in the morning starts out already knowing what has been tried before. And on the customer’s side, the practical effect is being served by someone who remembers the context — without anyone having to tell the whole story again. It holds for IT support just as much as for projects.

Adoption in waves, and what to measure

We never start by automating. The order that works is: wave 1, AI reads and summarises (near-zero risk, immediate gain); wave 2, AI queries systems and answers with a source; wave 3, AI drafts deliverables with mandatory review; wave 4, an agent runs reversible, tightly bounded tasks. Each wave only opens once the previous one has a stable indicator.

And measure four things from day zero: task cycle time (against the earlier baseline), rework rate on what the AI produced, source coverage — how many answers cite a verifiable origin — and cost per task, including token consumption. That last one takes exactly the same discipline as FinOps: without visibility of consumption per use case, the bill grows and nobody knows where it came from.

To go deeper, it is worth combining this material with the content in Inove Academy — in particular the e-book on Cybersecurity and data protection, which covers the access governance that underpins any AI project, and the FinOps calculator, useful for modelling the recurring cost before you scale.

In the end, the question that separates a pilot from production is not “which model should we use”. It is another one, far more tedious and far more useful: where does the context come from, who authorised that access, what can the AI do without asking permission, and how will we know, in numbers, whether it was worth it. Answer those four and you have a system; leave them unanswered and you have a demo.