Enterprise AI FAQ

Fifteen Questions Decision-Makers Actually Ask About Enterprise AI

Crisp answers covering strategy, governance, risk, implementation and ROI. Written for CTOs, CIOs, heads of risk and program owners - not for technologists looking for tutorials.

Build vs Buy, Model Choice, and What an AI Strategy Actually Is

The decisions that fix the cost and risk profile of everything that follows.

When should companies build AI in-house vs buy?

Build in-house when the AI capability is a durable competitive differentiator, when the underlying data is sensitive enough that it cannot leave your control, or when off-the-shelf systems cannot meet your latency, throughput or integration constraints. Buy when the capability is generic (transcription, generic chat, document OCR), when time-to-value matters more than control, or when the underlying models change faster than your team can keep up. Most enterprise programs end up hybrid: buy the foundation models, build the orchestration, retrieval, governance and integration layers.

How do you decide between a general LLM, a domain-tuned model, and a RAG system?

A general LLM fits when the task is open-domain and freshness of internal data does not matter. A domain-tuned (fine-tuned) model fits when you need consistent task-specific behavior at scale and you have hundreds-to-thousands of high-quality examples. A RAG system fits when answers must be grounded in your private corpus, when documents change frequently, or when you need source attribution for compliance. In enterprise practice, RAG is the default starting point; fine-tuning is added later for narrow tasks where RAG accuracy plateaus.

What does an AI strategy actually contain that distinguishes it from a technology roadmap?

A technology roadmap lists what will be built and by when. An AI strategy answers four prior questions: which decisions in the business should AI inform, what is the acceptable risk profile per decision class, what data is available and under what constraints, and what changes in operating model and governance are required to absorb AI outputs into existing workflows. Without those answers, a roadmap is just a list of demos.

Maturity, Frameworks, and the Minimum Baseline

The questions that determine whether AI in your organization is a controlled capability or an accumulating liability.

How do you measure AI governance maturity?

Maturity is measured across five dimensions: inventory (do you know every AI system in production), risk classification (is each system classified by impact and regulatory exposure), controls (are model, data and prompt controls documented and enforced), monitoring (are drift, hallucination and incident rates tracked), and accountability (is there a named owner per system and an escalation path). A practical baseline checklist with these dimensions is on our AI Governance page.

Which framework - NIST AI RMF, ISO/IEC 42001, or the EU AI Act?

They serve different purposes and most enterprises end up using more than one. NIST AI RMF (US, voluntary) is a risk-management methodology - best for building your internal program. ISO/IEC 42001 (international, 2023) is a certifiable management-system standard - best when you need an external audit signal. EU AI Act (EU, binding from 2025/2026) is law - mandatory if any of your users, customers or deployments touch the EU. Start with NIST AI RMF for structure, layer EU AI Act compliance for any EU-touching system, and pursue ISO 42001 certification when commercially required.

What is the minimum governance baseline before any production deployment?

Six controls cover the minimum: (1) a documented use case and intended user, (2) a named accountable owner, (3) a data lineage record covering training, retrieval and prompt sources, (4) a tested rollback or disable mechanism, (5) logging of inputs, outputs and decisions, and (6) an incident-response procedure with defined severity levels. Anything beyond this is desirable; below this, the system should not be in production.

What Actually Goes Wrong in Production

Concrete failure modes, in the order they appear in real incident reports.

What are the biggest risks of LLM deployment in regulated industries?

In order of frequency in production incidents: data leakage through prompts and embeddings, hallucinated answers presented as authoritative, prompt injection from untrusted document content, unauthorized actions when LLMs are given tool access, and silent drift in model behavior across vendor updates. Each requires a specific control rather than a single generic mitigation.

How do you prevent hallucinations in production AI assistants?

Hallucinations cannot be eliminated but they can be constrained. The effective controls in order of impact are: grounding every answer in retrieved sources via RAG, requiring source citations in the response schema, rejecting or escalating low-confidence answers, narrowing the assistant scope so that out-of-domain questions are routed to a fallback, and adding a verification step (rule-based or second-model) for high-stakes outputs. Temperature tuning and prompt engineering help marginally; architecture changes help structurally.

When does an AI deployment cross the EU AI Act high-risk threshold?

The Act lists eight categories where AI is high-risk by definition: biometrics, critical infrastructure, education, employment and worker management, access to essential services, law enforcement, migration and border control, and administration of justice. Any AI system that materially influences a decision in those domains triggers high-risk obligations: risk management system, data governance, technical documentation, logging, human oversight, accuracy and robustness, and post-market monitoring. Most enterprise AI assistants are not high-risk; AI used in hiring, credit, insurance underwriting or medical triage typically is.

Architecture and Deployment Choices

The technical decisions that determine production success.

When does RAG outperform fine-tuning?

RAG outperforms fine-tuning whenever the answer depends on information that changes (policies, prices, inventory, documents updated weekly or more often), whenever source attribution is required (compliance, legal, medical), and whenever the knowledge base is large enough that a fine-tuned model would forget most of it. Fine-tuning outperforms RAG when the task is consistent behavior on stable patterns - extracting fields from a fixed form layout, writing in a specific tone, classifying into a stable taxonomy. In practice, most enterprise systems start with RAG and only add fine-tuning when a specific narrow task plateaus on retrieval alone.

Should we deploy AI in our own cloud or use vendor SaaS?

Use vendor SaaS when your data is non-sensitive, your scale is too small to justify infrastructure, or your team lacks AI operations expertise. Deploy in your own cloud (private cloud or on-premise) when data residency, regulatory exposure or vendor lock-in costs make SaaS unacceptable. The intermediate position - vendor SaaS with a private deployment of the same models in your tenant (Azure OpenAI, Bedrock, Vertex) - is the most common enterprise choice because it preserves data-control while transferring infrastructure burden.

How long does a typical enterprise RAG deployment take?

A scoped enterprise RAG pilot on one document corpus takes 6-10 weeks from kickoff to a user-facing pilot, assuming clean data access and clear evaluation criteria. Production hardening - access control, audit logging, monitoring, integration with identity systems - typically adds another 8-12 weeks. Programs that try to compress this into 4-week timelines usually re-spend the savings on remediation after pilot launch.

Measuring Whether It Was Worth Doing

Timelines, high-yield use cases, and the metric stack that survives executive scrutiny.

What is the typical ROI timeline for enterprise AI projects?

AI projects that target operational efficiency in knowledge-heavy work (legal, compliance, support, claims) typically show measurable ROI within 6-12 months when scoped to a single workflow with clear baseline metrics. AI projects that target revenue generation or strategic capability (personalization, decision support, product features) typically show ROI on a 12-24 month horizon. Programs that cannot define their baseline metric before kickoff usually cannot demonstrate ROI at any horizon.

Which AI use cases tend to produce measurable ROI within 12 months?

Five categories consistently produce measurable 12-month ROI in enterprise deployments: internal knowledge retrieval that replaces ad-hoc searches across documents, customer-support assistants that deflect tier-1 ticket volume, document processing automation (invoices, contracts, claims), code-generation assistants for developer productivity, and meeting/transcription summarization where time savings are directly attributable. Common to all five: a stable baseline metric existed before the AI project.

How do you measure the business impact of an AI assistant?

Three layers of metric, in order: usage (active users, queries per user, session length - proves adoption), task outcome (resolution rate, time-to-answer, deflection rate - proves utility), and business outcome (cost per ticket, agent capacity, customer satisfaction - proves ROI). Most failed AI assistant deployments measure only layer 1 and then cannot defend continued investment. Define all three layers before launch.

Where to Go Next

This FAQ summarizes; the framework pages explain the underlying methodology.

AI Governance Framework

The 5-level maturity model, the practical baseline checklist, and the risk taxonomy referenced throughout this FAQ.

Read the AI Governance page

Methodology

How the strategy, architecture and governance phases of an engagement actually run - deliverables, decision artefacts, timeboxes.

See the Methodology page

Case Studies

Anonymized engagements across healthcare, financial services and manufacturing - what was built, what worked, what we would change.

Browse Case Studies

Free download

AI Pre-Production Review Checklist

22 failure modes AI generators ship into production code, in 7 categories - with detection signals and the architect's mitigations.

Email me the checklist

Have a Sixteenth Question?

Bring it to an Architecture Review. The structured conversation will produce a clearer next step than any FAQ entry could.