The next use case is the real test of your AI platform.

For a non-technology-native organisation with more than 10,000 employees, I would put a shared AI foundation firmly on the board agenda. At that scale, repeated knowledge work, fragmented systems and different local solutions can make common services particularly valuable. The employee count is a useful screening signal, not a technical threshold or a guarantee of return.

A smaller engineering-intensive business may need substantial integration. A much larger business may initially get more value from configuring existing enterprise AI products well. Count the people doing suitable tasks, the frequency of those tasks and the systems involved. Total headcount is a poor substitute for that analysis.

The investment case becomes stronger when several valuable workflows need the same identity controls, data connections, evaluation tools or operating support. A service team, a commercial team and a finance team may each need reliable access to product and customer information. Building that access once can be useful. Funding three teams to recreate it is expensive.

Start with a short list of named workflows and accountable business owners. Establish today's cycle time, error rate, manual effort and service outcome. Then ask what existing software already provides. If the remaining need is mainly drafting, summarising and general research, a purchased enterprise assistant may be sufficient. A proprietary portal has to offer more than your logo on a chat box.

The reference architectureA reusable map of the capabilities and boundaries a solution needs. It guides a company’s design; it is not a vendor shopping list or a finished deployment plan. separates business applications from the reusable capabilities beneath them. It is industry agnostic: a service response, a finance reconciliation and a maintenance assistant can use the same model access, identity checks and release tools while retaining their own business rules. These are logical responsibilities. Several may be delivered by one purchased product or by existing enterprise services.

Read the diagram from the business experience down to its foundations. The controls on the right apply across every layer. The stack is a capability map, not a claim that every request travels through six sequential steps. Core systems remain the authoritative source for business transactions; the platform connects to them through approved interfaces.

The first important separation is between a workflow and the model it calls. OrchestrationThe coordinator that decides which steps run, in what order and when a person must approve the next action. determines the approved sequence of work; the model supplies a prediction, interpretation or draft within that sequence. A model gatewayA common access point for AI models that can route requests and apply usage controls. The team still tests each model for the job it will do. can centralise routing and consumption controls. The team should be able to change a model without rewriting every business application, while still retesting its behaviour.

The second separation is between asking for information and changing a business record. An APIA defined way for one piece of software to request information or an action from another, such as checking an order’s status. is an agreed way for systems to communicate. Model Context Protocol, or MCPModel Context Protocol gives AI applications a standard way to discover tools and exchange context. It does not itself grant permission to use a company’s systems., standardises how AI applications discover tools and exchange context. Neither is a reason to give an application broad access. Expose narrow operations, such as checking an order or preparing a draft adjustment, with permission and validation checks at the tool boundary.

Source documents: MCP architecture and scope.

The architecture does not require you to train a large language model or replace the company’s data estate. It requires the team to specify interfaces, access boundaries and operating responsibilities. Before approving implementation, ask for a deployment view showing where services run, which data may cross each boundary, what is reused and how the system is recovered. That is how this reference becomes a design for your company.

There are three broad choices, and a company can use all three for different needs. Buying and configuring an enterprise assistant is often the fastest route to common productivity tasks. Building a shared integration layer becomes attractive when valuable workflows cross systems or require a distinctive experience. Operating selected models yourself adds control over deployment but also adds engineering, capacity planning and maintenance.

For a non-technology-native company, my starting preference is managed infrastructure with a deliberately small amount of custom software. Reuse identity, monitoring and deployment capabilities that already work. Build the connections and workflow behaviour that matter to the business. Avoid recreating commodity services merely to call the result independent.

Low-code tools can be excellent for bounded workflows. Custom development is useful where user experience, integration or operating requirements exceed those tools. Require the delivery team to explain the choice in terms of the task and its lifetime cost. A preference for one tool should not determine the company's architecture.

For model choice, compare quality on your tasks, response time, usage cost, deployment options and contractual treatment of data. Keep a route to change providers, but recognise that switching models requires renewed evaluation: prompts, tool behaviour and output quality can change. Self-hosting an open model can address a particular constraint; it is not automatically cheaper or safer.

Choose the runtimeThe computing environment that actually runs an application, including processing, storage, networking and the services it depends on. to fit the workload. Managed functions or application services can suit short, intermittent tasks with little infrastructure administration. Containers can suit longer-running workers, custom dependencies or greater runtime control. A managed container service may be enough; running a cluster yourself adds operational responsibility. Select regional deployments where latency, resilience or applicable data requirements justify them, rather than building a global estate on day one.

A multi-cloud or multi-model design should solve a specific problem such as resilience, geographic requirements or quality differences. Every additional provider adds operational work. The board should see which dependency is being reduced and what the extra complexity costs.

A model does not know which version of your pricing policy is approved or which order has just changed. The data layer supplies that context. Start with the information needed for the first workflows, with named owners and clear definitions, rather than copying everything into a new repository.

For documents, retrieval-augmented generationFinding relevant, permitted information and giving it to a model with the question, like opening the right reference book before answering., or RAG, means finding relevant passages and giving them to the model with the question. It is closer to opening the right reference book than teaching the model your whole business. The answer still needs to be evaluated, and retrieval must exclude information the user is not authorised to see.

For core-system records, a governed read replicaA maintained copy of selected records used for reading or analysis. It may lag behind the original system, so freshness and access rules matter. or curated data product can serve frequent analysis without placing the same query load on operational systems. A replica is a controlled copy, not a new source of truth. Define what is copied, how fresh it must be, how permissions and deletions propagate, and how errors are detected. Use a live API where the task requires current state. A stock decision cannot silently rely on yesterday's availability.

Carry the user's authorisation context through retrieval and tool access. Logging into the front door does not entitle someone to every record behind it. Customer-facing applications require a deliberately separate trust boundaryA dividing line between environments or users with different permissions. Crossing it requires explicit checks; being inside one area does not open every other door., curated data and tested isolation; do not expose the employee environment simply by changing its interface.

Source documents: Microsoft guidance on identity and authorised retrieval.

Multi-agent architectureSeveral AI-driven workers divide a task between them. This can help specialist or parallel work, but adds coordination, cost and failure points. becomes useful when a task benefits from distinct specialist work or parallel investigation. It also creates more hand-offs, model calls and opportunities for errors. Compare it with a simpler workflow on the same evaluationA repeatable test of whether an AI application completes representative tasks to the required quality, safety, time and cost standard. set before committing. More agents are not evidence of a better platform.

Source documents: Anthropic guidance on choosing workflows and agents.

Do not set the budget as a fashionable percentage of revenue or multiply all employees by an assumed productivity gain. Price the next useful capability. Include the delivery team, integration, security and quality assurance, licences and consumption, adoption, support and eventual retirement. Existing employees have an economic cost even where no additional cash leaves the company.

Separate the cost of the common foundation from the cost of each use case. Otherwise the platform can appear cheap because business units pay for integration, while the business units appear inefficient because they carry infrastructure used by everyone. Show both the full enterprise cost and the incremental cost of adding another workflow.

Evaluate benefits with the same discipline. Hours released create capacity; they become financial savings only when spending is avoided or the operating model changes. Faster service can create value, but revenue claims need an attributable commercial mechanism and should be assessed at contribution margin. Do not count the same benefit again as both productivity and headcount savings.

Test the case under lower adoption, higher review effort and higher consumption. Include the cost of failures and support. Compare the platform with buying and configuring existing tools, and with a smaller integration scope. Fund enough to establish proof, but do not commit to an enterprise-wide rollout before the next decision can be made on evidence.

IT, digital and innovation can each provide a sensible organisational home. What matters is a direct route to C-level decisions and the practical ability to obtain access, prioritise, release and operate software. Innovation without a production route becomes a demonstration unit. IT without a delivery mandate can turn every experiment into a waiting list.

My starting recommendation is a small internal AI platform DevOpsA way of working in which engineers build, release and run software together, using feedback from live operation to improve it. team anchored by at least two experienced engineers working as peers. One might bring deeper platform and integration expertise, the other stronger application and AI delivery experience. Both should understand the architecture, review each other’s changes and be able to operate the critical services. Two is a starting point for shared ownership, not a claim that two people can provide every skill or round-the-clock global support.

Hire people who have shipped and operated software, can diagnose failures and can explain their technical trade-offs. Pay for that judgement. Familiarity with low-code products alone does not establish it, and a large junior team is not a substitute for it. In a global business, share regional engagement and operational responsibilities deliberately, with overlap for review and handover. Fund additional cover when availability commitments require it.

The team reports directly to a C-level sponsor against one prioritised roadmap. Name a responsible engineer and a reviewing peer for each service, and a business owner for the outcome. Set delegated budget and release authority within agreed boundaries. The sponsor settles cross-business priorities and removes blockers; engineers make technical decisions within that mandate. Shared ownership needs explicit responsibilities, without manufacturing a new management hierarchy.

Use specialist partners for a difficult integration, additional builders or independent quality assurance. Keep source code, deployment accounts, architectural decisions and operational knowledge accessible to the internal team from the first day. Build, operate and transfer should develop internal capability while delivery happens; it should not leave the company buying back its own knowledge at handover.

Assess performance through working releases, reliability, sound prioritisation and the ability to remove delivery constraints. When progress stalls, distinguish a capability problem from missing access, unclear priorities or inadequate resources. Fix the constraint, set explicit delivery expectations and replace persistent underperformance where those conditions are in place. A senior title does not excuse an absence of delivery.

For the CEO, challenge both unqualified enthusiasm and blanket refusal. Ask the CIO which specific risk prevents a proposed release, what bounded alternative would address it, and who will make the decision by when. Involve legal and security early enough to design that route together. The objective is usable authority within clear limits, with a team capable of exercising it.

Give builders usable development environments, approved access and a route to production. Separate development, testing and live operation. Start sensitive workflows with read-only access or draft outputs, and introduce write actions through narrowly scoped tools with validation and appropriate human approval. The ability to read an order should not automatically include the ability to change it.

Test realistic tasks, permission boundaries, malicious instructions hidden in retrieved material, incorrect tool use and failure recovery. A model's answer is not an authorisation decision. Keep permissions and consequential-action checks in enforceable application controls. MCP standardises connections; it does not make every connected tool trustworthy.

Source documents: MCP security guidance.

Release first to a bounded group, observe quality and failures, and expand only against agreed criteria. Maintain a way to disable a tool or roll back a release. Give every application an owner, a support route and a retirement decision. A growing collection of unowned micro-apps will eventually become the next application-portfolio problem.

Set model and usage limits by workload, team or user, rather than giving every task unlimited access to the most expensive model. TokensThe small units into which a model divides input and output. They help measure model consumption, but do not capture every cost of running an application. are units of model input and output, and a useful consumption measure. Also monitor tool calls, runtime, storage and paid external services: a token cap alone cannot cap the whole bill.

Combine alerts with enforced quotas, maximum output sizes, timeouts, retry limits and limits on an agent's steps. Define what happens when a cap is reached: stop, queue work or use an approved fallback, with a controlled exception process for critical services. Budget alerts alone do not prevent spending, and delayed provider metering can leave exposure before a limit takes effect. Test enforcement and allow headroom.

Source documents: Microsoft AI gateway quotas and monitoring.

Evaluate quality and cost together. A cheaper model that creates substantial rework can cost more per accepted result. Monitor the cost of a successfully completed task, including review effort, rather than celebrating cheap calls or high activity. Protect sensitive information in logs as carefully as in the application itself.

Personal productivity should make useful AI available across the organisation. Onboarding matters, but it is the beginning of adoption. If the monthly report celebrates activated accounts while nobody can identify recurring tasks that improve, the investment is losing direction.

Use a live view of the portfolio that connects each workflow to its owner, stage, next release, current constraint and business measure. Require evidence from real use. A platform team should be able to explain what went live, who uses it repeatedly, what failed and what changed as a result.

Scipio & Partners helps executive teams choose the architecture, size the investment and appoint the people required to deliver. We have established these capabilities for clients globally through build, operate and transfer: build the foundation around valuable workflows, operate it with the client until delivery and support are dependable, and transfer the capability with clear ownership.

Transfer should be designed at the start. Agree ownership of code and accounts, internal counterparts, operational documentation and acceptance criteria. The receiving team should demonstrate that it can release, monitor and recover the service. A handover presentation alone does not establish that capability.

The board's next decision should be specific: which work to improve, which shared components it needs, who is accountable and what evidence releases the next investment. A platform deserves to grow when it makes the business more capable and the next useful application easier to deliver.