In regulated industries, agentic AI should be governed through an integrated platform rather than built in-house, to limit costs, risks and fragmentation.
Regulated sectors are familiar with this scenario: new capacity appears. The teams then launch one-off solutions, each designed to solve a specific problem. Very quickly, the organization finds itself managing fifteen tools that were never designed to work together, and teams spend more time integrating them than producing useful results. That’s what happened with DevOps toolchains, and that’s exactly what’s starting to happen with agentic AI.
The progressive cost of platforms built in-house
When AI-assisted coding tools began to generate real productivity gains, many organizations had the same reflex: go further. A code wizard here, an internal AI gateway there, a few open source templates, a bit of custom orchestration, and suddenly the team is talking about a platform.
There is a reason for this. Technical teams have a natural tendency to build, and this reflex is not bad. It is by building that engineers learn, teams develop their skills, and truly new problems find answers. The same “do it yourself” energy that marked the beginnings of DevOps has created remarkable tools and practices.
But regulated organizations need AI adoption that is scalable, governable and consistent across the enterprise. Before going any further, we must therefore clearly distinguish what is at stake.
- Building means assembling agentic frameworks, orchestration layers, custom governance, and the infrastructure needed to make it all work, including compute, storage, databases, and networking. The organization then becomes the publisher of its own platform.
- Buying means adopting a platform that already unifies models, tools, orchestration and governance across the entire software development cycle. The organization then becomes a user of the platform.
In a regulated environment, this distinction is crucial.
The real complexity is in the orchestration layer
What sets agentic AI apart from previous generations of tools is not the model itself, but the orchestration around it. The centerpiece of any modern AI system is now the agentic framework: the logic that determines which tools to call, in what order, with what safeguards and with what traceability.
This is where the current fragmentation takes hold. Teams adopt their own agentic frameworks and coding tools, each making rational choices at their own level. But these choices pile up. Each framework adopted separately creates a new point of integration, a new potential governance gap, and a new silo that the organization will need to absorb or work around.
Building an internal agentic AI platform in the banking or insurance sector requires a multi-year commitment to orchestration engineering, with a regulatory scope that most organizations underestimate. We must first manage the agentic frameworks: selection, integration, monitoring of behavioral deviations and management of obsolescence. These are ongoing responsibilities, with no real off button. Next comes increased security. Agents who access the code and infrastructure must meet requirements much higher than those of a traditional SaaS integration: protections against prompt injections, sandboxing, integration with SIEM and DLP tools, red team type tests, etc.
In frameworks like DORA and the European law onartificial intelligencean internal AI system functions like a regulated system. The organization then defines the risk classification itself, maintains the documentation and produces the evidence necessary for the audit throughout the life of the system. Each agent integrated into the SDLC also creates, in its own way, a mini-product that the teams must maintain despite changes in tools, frameworks and organization.
Added to this is a cost rarely taken into account in the first analyses: all the engineers mobilized to build the platform are no longer necessarily available to modernize an existing chain, reduce the security debt or accelerate a critical delivery program.
What the DevOps era has taught us
The era of DevOps provides a useful point of reference. The teams did not seek to intentionally create fragmented toolchains; they simply made progressive and rational decisions: a better CI tool here, a preferred SCM there, a security scanner added as a complement, a separate secrets manager, another deployment orchestrator.
Each choice made sense taken in isolation. But, taken together, these decisions have created a multiplication of tools that is difficult to control: cumbersome integrations, inconsistent governance, duplication of efforts and lack of a unified vision on the SDLC.
The industry spent much of the next decade consolidating around platforms, precisely because these many tools were expensive and difficult to audit.
Agentic AI follows the same trajectory. Organizations that make a real choice of platform now, rather than a succession of one-off choices, will gain years of catch-up in a few months.
Three questions to guide decisions
Rather than approaching the subject through a generic “build vs. buy” debate, it is appropriate to rely on three fundamental questions:
- Is the need really unique? Build is justified when the organization has workflows that no vendor supports, deployment modes that no platform can satisfy, and a real desire to invest in platform engineering as a sustainable capability. That said, modern platforms increasingly support regulated environments through cloud, self-hosted, or dedicated single-tenant deployments. For goals like accelerating code reviews, migrating pipelines, handling security alerts or automating tests, existing platforms are already delivering results in comparable organizations.
- How much regulatory burden can the organization actually handle? Building means becoming the owner of the system in the sense of ICT risk frameworks, an AI provider in the sense of emerging regulations, and responsible for the behavior of the models, documentation and monitoring. Buying does not eliminate regulatory liability, but shifts platform obligations to a specialist provider and allows compliance teams to focus on AI uses rather than infrastructure.
- What is the timetable? If the board expects visible results within the teams within 12 to 24 months, an internal project that extends over several years is out of step with this expectation from the start.
The figures clearly show this gap. For a regulated organization of around 200 developers, building an internal platform on a cloud AI foundation typically costs around €1.2 million in the first year, including engineering efforts, infrastructure, integration, security and compliance. It takes 6 to 12 months before having a project truly ready for production, and 2 to 3 full-time people dedicated to maintaining its stability. In practice, the first real use case arrives after 12 to 18 months, at least.
Conversely, an agentic AI platform designed for this purpose costs around 380,000 to 425,000 euros for the same number of developers, with an initial deployment in a few days and early productivity gains of 15 to 25% once agents are integrated into daily workflows. The first use case then arrives in a few weeks, and not after a few years.
This gap represents the difference between delivering a return on AI investment in the same fiscal year and explaining to the board why the organization is still developing the infrastructure.
What an integrated platform really does
A good platform solves four problems that home-built approaches repeatedly mishandle.
- Agnosticism regarding models and tools: the agentic AI ecosystem is evolving too quickly to bet on a single model or framework. A platform that can support any backend model and integrate cleanly with existing coding tools gives organizations freedom without losing consistency. The platform then becomes the governance layer, not a barrier to adoption.
- Reliable safeguards around non-deterministic agents: agentic systems are, by nature, probabilistic. It is therefore possible to integrate them into deterministic workflows that impose code reviews, security scans and compliance checks before AI-generated content reaches production. Agents speed up task execution, while the platform ensures accountability. This logic is already appearing in financial services. For example, Barclays uses AI assistants to help development teams with code generation, code explanation, test generation and refactoring, as well as root cause analysis to resolve failed jobs faster. The challenge is not only to add AI to development, but to include it in a common DevSecOps platform, with the workflows and controls necessary for controlled adoption.
- Personalization in a governed framework: Most users access agents through a shared catalog and immediately get value in a governed environment. More advanced users can adapt agents to their context by adjusting system prompts and certain parameters, without writing a line of code. Teams with real differentiated needs can create their own agent flows and publish them in the catalog, to transform internal work into collective capacity.
- AI serving the entire organization: the productivity of development teams is often the entry point, but rarely the ceiling. The platform can also serve project managers, infrastructure engineers, testers, security and compliance teams with agents tailored to their needs, while remaining in the same governance layer.
Where to place customization in architecture?
Personalization is a legitimate need in regulated industries. The challenge is not to exclude it, but to determine where it is really needed. Intelligent orchestration ensures consistency and flexibility, without imposing uniformity. Everyone operates in the same governance layer, with a degree of flexibility adapted to needs.
The consolidation seen in DevOps applies directly here. The real cost came not from the tools themselves, but from technical decisions accumulated faster than organizations could govern them. Agentic AI deserves the same rigor.
