Observations from the First Wave of Enterprise AI and What Comes Next

At a media group, invoices arrive by email and post themselves into the accounting system. At an industrial company, an assistant inside Microsoft Teams answers IT tickets. At a medical technology company, a tool drafts responses to public tenders using the company’s own documentation.

All of this is running today. I lead the AI division of a technology consultancy, and what follows are observations from a year of AI deployments across a dozen companies: multinationals and mid-sized firms, mostly in Spain, usually working with a single division at a time. This post is what the work looks like from inside, and what it suggests about what comes next.

Three kinds of work

The projects span different sectors, systems, and budgets, but they collapse into three kinds of work.

Automating data entry

A large share of office work is people translating between formats: email to ERP, PDF to spreadsheet, attachment to database row. Multimodal models read documents, images, and photos directly, which opens up processes that could not be automated before, or that ran on clunky RPA.

At one client, salespeople register commercial proposals by blind-copying an email address. The deal appears in the CRM with the fields filled in. The same pattern repeats across companies: invoices extracted from email, purchase orders entered into SAP. It is the least glamorous category and the one with the highest volume of projects.

What has surprised us is the distance between a working prototype and a production system. The prototype takes a couple of days. A system reliable enough for accounting or order management takes closer to two months: you have to mitigate the non-determinism of the models, handle the edge cases, satisfy the security reviews, and deploy and test it inside the client’s environment. And these automations often sit in critical areas where mistakes are costly.

Software that could not exist before

AI made custom software cheap to produce. Projects that needed a six-figure budget and nine months now take weeks, and this is quietly breaking the build-versus-buy logic that governed enterprise IT for twenty years.

One client asked us to build an application for managing event staging that would never have been budgeted at pre-AI prices. Others are starting to consider replacing per-seat SaaS tools with custom software.

Even when a custom solution is the right choice, what often slows us down is the insistence on building it with no-code platforms. In our projects, writing code is faster and gives better results, partly because AI coding assistants work well with code while no-code platforms are too rigid to benefit from them. On the bright side, this is changing quickly, and clients are getting used to the new reality.

Assistants connected to company knowledge

Companies sit on documentation nobody reads and expertise locked in a few heads. It is now practical to make that knowledge answer questions, and increasingly to act.

At a consumer-goods group, an assistant helps HR technicians run employee onboarding. It answers questions about the process, emails managers to request approvals, and creates tasks in the planner. The same shape appears elsewhere: a chatbot that resolves IT tickets, another that answers questions against a product catalog, the tender tool from the opening paragraph.

What these projects reveal, almost every time, is how little is actually written down, well organized, or up to date. An AI project is often a good excuse to improve the knowledge foundations of a company.

What comes next

Almost everything that comes next is generated by the first wave itself. Maintenance exists because systems were deployed. Data work becomes urgent because projects keep hitting the same messy foundations. Ambitious projects become possible because the first wave built trust and removed risk.

Operating what was built

Every deployed system needs operating, and the need shows up sooner than anyone plans for. Upgrading to a more recent model usually means retesting and tuning the solution, because the new model behaves differently enough to change the results, and upgrades come often. We have seen a knowledge base that quietly stopped being updated; the assistant kept working, giving answers that were a year out of date. We have seen two applications carrying duplicated copies of the same knowledge base that should have been one source.

And the inputs themselves drift: the documents, formats, and requests a system receives change over time, and AI systems are more sensitive to this than classic software. Operating means monitoring quality, keeping sources current, managing cost, governing access, handling model migrations, and driving adoption.

None of this argues for heavy governance from day one. Moving fast with light rules is the right call early on; waiting until the rules are decided is how companies end up with near-zero adoption. But as systems accumulate, it pays to consolidate the patterns that have proven themselves and to introduce stronger governance, and that work grows with the number of systems running.

Closer to the knowledge and data layer

That duplicated knowledge base points at something larger. In a good number of the systems we have shipped, the knowledge and data part was relatively simple: one source, often small or already structured, wired up for that project alone. That is part of why the first wave shipped fast, and it is also a sign of where companies are in the adoption curve: the obvious quick wins get implemented first, precisely because they don’t need much from the knowledge and data side.

As those get done, the use cases that remain tend to involve more complexity on the knowledge and data side. The tender tool is an early example; it draws on multiple sources that must stay current, curated, and owned. So AI work moves closer to the knowledge layer, and the layer itself grows more complex: shared across applications instead of rebuilt per project, kept current by a named owner, and connected both to internal systems and to the general tools like Claude or Copilot. One client is already asking us to build exactly this.

In practice it means the disciplines data teams apply to the warehouse (ownership, documentation, quality, access control) start being applied to material that gets that treatment much less often: guides, policies, product documentation, everything an AI reads.

You should be wary of buying the knowledge layer as somebody else’s product. Some solutions promise to organize all your company’s knowledge for you, which means your organizational memory ends up in their proprietary schema, behind their retrieval layer, at a vendor that might not be the best option in four years, might change its pricing, or might constrain what you can build. The product’s structure also starts shaping your knowledge rather than the other way around. Build the layer as a practice the company owns, keep it in simple, portable formats that a better model can be pointed at in 2029, and rent the intelligence that runs on top of it.

More ambitious projects

The ambitious projects are the same projects that were prohibitive before, with part of the risk removed. Enterprises want de-risked outcomes more than they want ambition, and some large projects are becoming much less risky.

What made an ERP migration or a data warehouse rebuild prohibitive was largely archaeology: nobody fully understands the legacy system, its customizations, its undocumented rules, and excavating that understanding cost more than the change itself. AI is unusually good at exactly this: reading old code, mapping data models, generating the tests that make change safe. The organizational politics and the coordination with vendors remain, but the archaeology got much cheaper.

We are currently in that phase of a project like this for a client: an AI-assisted team taking control of legacy applications, documentation and understanding first.

Conclusion

I have watched client organizations get faster with each project: guidelines for testing AI applications with real users, established paths for provisioning resources and access, knowing which sign-offs are needed and getting them without a committee forming each time. The first project has to invent all of this, and the projects that follow inherit it.

That know-how can lean on outside partners, but it has to be owned inside the company, because it is what makes each new project cheaper and faster than the last.

The systems from the first wave are running. The maintenance they need, the knowledge organization they expose, and the larger projects they make viable are already visible in the work. That is where I believe the next years go.