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
14 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 -
Should you adopt a framework or write your own agent loop?
Adopt an agent framework when you need to move fast on common patterns, such as tool calling, multi-step plans, memory and tracing, and your team will follow its conventions. Write custom orchestration when the flow is mostly deterministic, the control and audit requirements are strict, or the framework's abstractions get in the way more than they help. Either way, keep your prompts, tools, policies and evaluations outside the framework so you can change it later.
Read the guide -
When does your knowledge assistant need a graph?
Start with vector RAG, ideally with hybrid search and reranking: it answers most questions that live in one or a few passages, and it is cheaper to build and keep fresh. Add a knowledge graph when the questions you must answer depend on relationships across many documents, such as who is connected to what, multi-step chains or themes across a whole corpus, and evaluation shows vector retrieval missing them. GraphRAG buys that reach with a costlier index, more maintenance and harder permission handling.
Read the guide -
Do you still need a retrieval pipeline if the model can read the whole dataset?
Use long context windows when you need to synthesise, summarise, or compare information across a single massive document in a single turn. Use RAG when you need to answer questions from a large, constantly updating enterprise repository where permissions, query costs, and latency matter. Most enterprise systems use RAG to find the right needle, and long context windows to understand the haystack that needle was found in.
Read the guide -
When is the extra thinking worth paying for?
Use a reasoning model when the task has several dependent steps, a verifiable right answer or a high cost of error: analysis, planning, complex extraction, code, multi-tool agents. Use a standard LLM when the task is simple, conversational, high-volume or latency-sensitive, where extra thinking adds cost and delay but not quality. Most systems use both, routing each request by difficulty or setting a reasoning effort per task, and deciding with evaluation rather than intuition.
Read the guide -
Which one should run your enterprise use case?
Use a small or specialised language model when the task is narrow, repetitive and well defined, runs at high volume, or must stay on your own infrastructure or device. Use a large frontier model when the task is open-ended, varied or needs broad knowledge and multi-step judgement. Most enterprise portfolios end up with both: a large model where breadth matters and smaller models for the high-volume tasks they handle well enough, chosen by evaluation on your own cases.
Read the guide -
What should you train, tune and test your AI on?
Use real data as the reference for anything that decides whether a model works: final evaluation, acceptance and monitoring should reflect the population and conditions the system will actually meet. Use synthetic data to fill gaps that real data cannot cover safely or in time: rare cases, adversarial tests, development environments without personal data, or balancing under-represented groups. Synthetic data generated from personal data is not automatically outside GDPR, and a model that only passes synthetic tests has not been shown to work.
Read the guide
Sourcing: build, buy or partner
5 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 -
Which model fits how your organisation will use AI?
Choose per-seat licences when many people will use an AI assistant regularly in their daily work and you value a predictable budget. Choose usage-based pricing when consumption is uneven, driven by processes rather than people, or still unknown, and you can meter and cap it. Most organisations end up with both: seats for broad productivity tools, usage for agents, integrations and automated workloads, with one place that shows cost against value.
Read the guide
Operating model
4 guidesWhat has to change for AI to leave the pilot and hold up in production.
-
What actually changes when you scale?
A pilot answers one question: can this use case deliver value with real data? Production answers a different one: can it keep delivering every day, with owners, monitoring, cost control and legal accountability. If the pilot did not define exit criteria, a baseline and a path to production from day one, scaling it is not the next step but a new project.
Read the guide -
Which comes first?
Do not wait for a perfect data platform before starting with AI, and do not start with AI while ignoring the data. Pick a few focused use cases, find out exactly which data each one needs and fix that data to the standard the case requires. A broad clean-up first makes sense only when the same data gaps block every valuable case, or when regulation requires data governance you do not yet have.
Read the guide -
How much should an AI agent decide on its own?
Keep a human approving each action when an error is costly, hard to reverse or affects people's rights, and let the agent act alone when actions are low-impact, reversible and well measured. Autonomy is not a yes-or-no choice but a setting per action, raised step by step as evidence accumulates. Whatever the level, every action must be logged and a person must be able to stop or override the system.
Read the guide -
Should you start again or decode what you have?
Rewrite from scratch only when the system is small, its rules are well documented or the business wants a different process anyway. When the value is in years of rules nobody has written down, use AI to recover them from the code as a specification that people review, then regenerate the system against the target architecture one domain at a time. AI speeds up the reading and the writing; it does not remove the need for experts who validate the rules and for tests that prove the new system behaves like the old one.
Read the guide
Governance and the EU AI Act
3 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 -
How should you assure the quality of enterprise AI?
Use automated evals to check every change, at scale and repeatably: fixed test sets, rule-based checks and LLM-as-judge scoring catch regressions that no team could find by hand. Use human expert review to define what good means, to judge cases where domain knowledge, risk or nuance decide, and to keep the automated judges honest. Quality assurance that holds up uses both: experts build and calibrate the evaluation, automation runs it on every release, and people review samples and high-risk cases in production.
Read the guide
Is your decision not on the list? Bring it to us.
Talk to an AI Expert