Essential
Required for the site to work. Always on.
AI decisions
Enterprise AI decisions, compared with criteria
Neutral guides to the choices every AI programme runs into: architecture, sourcing, operating model and EU AI Act roles. Each one starts with a short answer, compares the options side by side and says when each one fits.
Architecture and technology
8 guidesWhere models, data and integrations should sit, and what each option costs you in control.
-
Which one does your enterprise use case need?
Use RAG when the model needs to answer from knowledge that changes, must respect access permissions or has to cite its sources. Use fine-tuning when the problem is not what the model knows but how it behaves: a stable format, tone, vocabulary or narrow task it must perform consistently. Most enterprise knowledge use cases start with RAG; fine-tuning comes later, on top, when evaluation shows a behaviour gap that retrieval and prompting cannot close.
Read the guide -
Does your use case need an agent or a good assistant?
A generative chatbot answers questions and drafts content; an agent plans and executes multi-step tasks in your systems. If the value lies in the answer, a well-grounded chatbot is enough and far cheaper to govern. If the value lies in getting work done across tools, you need an agent, and with it permissions, audit trails and human checkpoints designed in from day one.
Read the guide -
Which one should automate your process, and when should you combine them?
Use RPA when the steps are fixed, the inputs are structured and the same result is expected every time; it is predictable and easy to audit. Use AI agents when the work involves reading unstructured content, interpreting context or handling exceptions that a script cannot anticipate. In most real processes the best design combines them: the agent reads, classifies and decides within limits, and deterministic automation executes the steps that must never vary.
Read the guide -
How should an enterprise choose?
Choose by use case, not by camp. Proprietary models via API are usually the fastest way to strong general capability with little operational burden; open-weight models win when you need full control of data and deployment, deep customisation or predictable cost at high volume, and you have the team to run them. Most enterprises end up with both, behind an abstraction layer that lets them switch.
Read the guide -
Where should your models run?
Decide by data, not by ideology. Cloud AI APIs are the default for most workloads because they give strong models with little to operate; sovereign or on-prem deployment is justified when the data, the regulator or the contract requires that processing stays under your control and EU jurisdiction. Most European organisations end up hybrid: sensitive workloads on infrastructure they control, the rest on cloud APIs under a governed gateway.
Read the guide -
Do your people need answers or documents?
Enterprise search returns a ranked list of documents and leaves the reading to the user; RAG retrieves passages and generates an answer that cites them. Choose search when people need to find and read the source, and RAG when they need a synthesised answer to a question spread across several documents. RAG depends on good search underneath: if retrieval is poor, the answer will be poor too, only more convincing.
Read the guide -
When should a conversation replace the menu?
An IVR routes calls through fixed menus and is predictable, cheap per call and easy to audit; an AI voice agent understands free speech, resolves requests by acting on your systems and hands over to a person with context. Choose IVR for simple, stable routing and legally scripted flows, and a voice agent when callers' needs vary and the goal is resolution, not routing. In the EU, a voice agent must tell callers they are talking to an AI, and call recordings fall under GDPR.
Read the guide -
How should your AI agents connect to your systems?
Use MCP when the same capability has to be reachable from several AI clients or agents, and you want one standard, governed tool layer instead of a connector per assistant. Use a custom API integration when a single application needs a deterministic, high-volume or transactional call path with strict latency, contracts and testing. MCP does not replace your APIs: an MCP server is usually a thin, curated layer on top of them.
Read the guide
Sourcing: build, buy or partner
4 guidesWhat to build, what to buy and who should do the work.
-
Which agents should you own, and which should you rent?
Buy agents for work that is the same in every company and lives inside one vendor's application; build them where the process is what makes you different, crosses several systems or needs controls you must be able to prove. Building does not mean training models: it means owning the workflow, the tools, the guardrails and the evaluation on top of commodity models. Whatever the mix, put every agent behind one governance layer so you can see, measure and switch what runs.
Read the guide -
When is the suite assistant enough, and when do you need your own agents?
If the goal is to help people write, summarise, search and prepare work inside the Microsoft 365 tools they already use, a suite assistant such as Microsoft Copilot is usually the sensible first choice. If the goal is to run a business process end to end across systems outside the suite, with your own rules, checkpoints and audit trail, you need custom agents. They answer different questions, and many organisations end up using both under one governance model.
Read the guide -
Should you bet on one provider?
A single vendor is simpler to buy, secure and support, and is often the right start. A multi-model strategy pays off once you have several use cases with different needs for capability, cost, latency or data location, or when one provider becomes a concentration risk. The decisive factor is not how many models you use but whether your applications are decoupled from any one of them, so the choice stays reversible.
Read the guide -
Who should build your AI?
Buy a platform when the need is standard and a product already solves it; build an in-house team when AI is part of your core advantage and you have a steady backlog; bring in a consultancy when you need to move faster than you can hire on a hard, cross-functional case and want the capability handed over. Most organisations end up combining the three, and the real decision is what goes where. A consultancy that does not plan its own exit is the most expensive option of all.
Read the guide
Operating model
1 guideWhat has to change for AI to leave the pilot and hold up in production.
Governance and the EU AI Act
2 guidesWho decides, who is accountable and what the EU AI Act asks of each role.
-
Which role are you, and what does each one owe?
You are the provider if you develop an AI system, or have it developed, and place it on the market or put it into service under your own name or trademark, including for your own internal use; you are the deployer if you use a system under your authority in a professional context. The role attaches to each system, not to the company, and it can shift: under Article 25, a deployer that puts its brand on a high-risk system, substantially modifies it, or repurposes a system into a high-risk use takes on the provider’s obligations. This guide is practical orientation, not legal advice.
Read the guide -
Who should decide what in your organisation?
Centralise what must be identical everywhere: policy, risk classification, approved models and platforms, the AI inventory and the regulatory evidence. Federate what depends on business context: use-case priorities, adoption and day-to-day accountability for results. A purely central model becomes a bottleneck as demand grows and a purely federated one fragments risk and spend, so the model that holds up at scale is a hybrid: a central committee with real authority plus embedded champions in each business line.
Read the guide
Is your decision not on the list? Bring it to us.
Talk to an AI Expert