Question 1

What is AI Enablement and how is it different from "AI strategy"?

Accepted Answer

AI Enablement is the structural redesign of how an organisation produces output around AI as a native capability. It is operating model work, not a tools roadmap. The unit of change is the workflow itself — how it is designed, what data it consumes, who owns the decisions it produces, and how it is governed. Most "AI strategies" are vendor lists with a governance addendum. AI Enablement is the redesign that makes AI compound rather than plateau.

Question 2

How is AI Enablement different from AI Readiness?

Accepted Answer

AI Readiness is the diagnostic-and-pilot service: maturity assessment, governance pack, use-case discovery, and a small pilot. It is how you safely enter AI. AI Enablement is how you redesign the organisation around it. Most clients who engage with us at the enablement level have already done — or skipped past — the readiness work. The two services serve different stages of the journey.

Question 3

Why won't my existing AI portfolio compound?

Accepted Answer

Most enterprise AI portfolios sit in "augmentation mode" — AI tools layered onto workflows that were designed for humans. The gains are real but local, and they plateau within 12–18 months. Compounding requires four structural conditions to be true at the same time: workflow redesigned around AI as a native capability, action-data layer built for real-time decisions, working feedback flywheel that turns operation into learning, and operating model redesigned for system supervision. Without all four, gains stay local. Our 90-second AI Pilot Compounding Audit scores any specific initiative against these conditions.

Question 4

What are the five enablement pillars you talk about?

Accepted Answer

Production function redesign, action-data layer architecture, decision systems and feedback loops, operating model and roles, and governance and model risk. These are the five interlocking disciplines that determine whether AI compounds for your organisation. We sequence them based on where your binding constraint sits, but they only work together — the whole point of compounding is that the pillars reinforce each other.

Question 5

How do you measure success in an enablement engagement?

Accepted Answer

Three categories. First, structural completion: the redesigned workflow is in production, the data layer is built, the decision rights matrix is operational, the governance machinery is producing evidence, and the role design has landed. Second, leading indicators: override rate stable in target band, decision logs queryable on demand, drift detection working, regulatory dialogue constructive. Third, business outcomes: cost-to-serve, cycle time, customer outcome quality, throughput per role — measured at the function level rather than per-task.

Question 6

How long does a typical engagement take?

Accepted Answer

A focused Diagnostic is 4 weeks. The full Strategy & Blueprint is 10–14 weeks. A complete Transformation Programme runs 9–18 months. A serious AI Enablement arc — diagnostic through to multiple workflows redesigned and operating in production — typically takes 24–36 months. Anyone promising faster has either scoped down the work or doesn't understand what they're committing to.

Question 7

Who from our side needs to be involved?

Accepted Answer

You need an executive sponsor at COO, CTO, CRO, or Chief Transformation Officer level. Beyond that, we typically work with operations leaders, data and engineering leadership, risk and compliance, HR (for the role redesign work), and the executives accountable for the priority value streams. We design the engagement around your team's capacity — we don't expect dedicated full-time backfill.

Question 8

How do you handle the political work?

Accepted Answer

Explicitly, and from day one. AI Enablement work touches operations, technology, risk, compliance, finance, HR, audit, and (for regulated firms) the supervisor's view of senior accountability. Coordinating that is the actual work — and it is organisational, not technical. The executive sponsor's job is political cover for the periods when no visible outcome has yet landed. We design the engagement to make that cover credible.

Question 9

What happens after the engagement ends?

Accepted Answer

You own the outputs, the playbook, the data layer, the governance framework, and the operating model design. Knowledge transfer is built into every engagement. Many clients move into a retainer relationship for senior advisory access; others bring us back six to twelve months later for the next priority workflow. There is no commercial pressure to extend.

Question 10

Do you embed alongside our team or work remotely?

Accepted Answer

Both, depending on the engagement phase. Diagnostic and Blueprint phases typically include weekly on-site sessions with your team plus continuous remote work between sessions. Transformation Programmes usually involve our practitioners embedded on-site for 2–4 days per week throughout the engagement. We are based in the UK but work across the EU and increasingly the US.

Question 11

Do you actually understand PRA SS1/23 and the EU AI Act?

Accepted Answer

Yes — and we treat them as the supervisory baseline rather than optional add-ons. Our practitioners have led model risk programmes inside PRA-regulated firms and have direct experience with the supervisory dialogue. SS1/23 and the EU AI Act shape every engagement from day one rather than being retrofitted at a deployment gate. By the end of Phase 1 you should be able to walk a supervisor through the redesigned workflow with full evidence.

Question 12

How do you embed governance into the workflow rather than bolt it on?

Accepted Answer

Three structural changes. First, the second-line risk specialist is part of the design conversation from day one rather than reviewing at a gate. Second, the workflow is designed from the start to produce the evidence governance needs (decision logs, lineage, override patterns, model risk file) as a by-product of running rather than a separate compliance exercise. Third, the governance reviews are substantive rather than ceremonial — "is this design defensible?" rather than "did you produce the document?" Done well, governance accelerates rather than blocks AI deployment.

Question 13

What about DORA — does it apply to our AI work?

Accepted Answer

Yes, almost certainly. DORA captures AI vendors as critical ICT third parties and imposes contract terms, exit strategies, supervisory access, incident reporting, and operational resilience testing. Most enterprise AI deployments fall within scope. We treat DORA compliance as a structural feature of the engagement rather than a separate workstream.

Question 14

How do you handle Consumer Duty for retail-facing AI?

Accepted Answer

FCA Consumer Duty is one of the most consequential constraints on retail-facing AI in the UK and is often underestimated by firms thinking of AI as a cost-reduction tool. Consumer Duty requires demonstrable good outcomes for retail customers (especially vulnerable ones) and the ability to monitor those outcomes continuously. We embed Consumer Duty alignment into the workflow design and the monitoring stack from day one.

Question 15

What if our regulator is not the PRA or FCA?

Accepted Answer

We work across UK, EU, and increasingly US regulatory regimes. The structural framework is the same; the specific supervisory expectations differ. We tailor the regulatory frame to your environment and engage your existing supervisory relationships rather than working around them.

Question 16

Do we need to have our data sorted before engaging?

Accepted Answer

No. In fact, the data layer is one of the things we redesign as part of the engagement. Most organisations think their data is in better shape than it actually is — and waiting for "data readiness" before rethinking workflows is one of the fastest ways to lose three years. We treat data layer rebuild as part of the workflow programme rather than a separate prerequisite.

Question 17

Are you tied to a specific AI vendor or platform?

Accepted Answer

No. We are vendor-agnostic on principle and we explicitly do not sell licences or have commercial alignment with any AI vendor or platform. Our advice is shaped by what fits the redesign, not by vendor relationships. Where the vendor landscape constrains the design, we say so explicitly and surface the trade-offs.

Question 18

What technology stack do you actually work in?

Accepted Answer

Python, PyTorch, scikit-learn for ML; OpenAI, Anthropic, Mistral for LLMs; BPMN 2.0, Camunda, bpmn.io for workflow modelling; Snowflake, Databricks, BigQuery for data warehousing; dbt, Airflow, Dagster, Prefect for orchestration; OpenLineage, DataHub, OpenMetadata for lineage and observability; Monte Carlo, Bigeye, Great Expectations for data quality; MLflow, Weights & Biases, Vertex AI for model management; Streamlit, Retool, Hex for internal tooling. We are technically opinionated in practice but recommend whatever fits the specific engagement.

Question 19

What is an "action data layer" and why does it matter?

Accepted Answer

Action data is captured to drive what happens next inside a workflow. It is structured to be consumed by other systems in real time, with no human intervention. It does not tolerate latency, missing fields, or inconsistent definitions — none of which matter much for reporting data but all of which break automated decisions. Most enterprise data is built for reporting. AI needs the action variant. The data layer rebuild is the work of redesigning data capture, structure, and lineage so the workflow can act on it.

Question 20

How do you handle vendor AI (Salesforce Einstein, ServiceNow, Microsoft Copilot, etc.)?

Accepted Answer

Vendor AI is unavoidable and is treated as part of the inventory. The governance framing is third-party risk first, model risk second — DORA-style contract terms, exit strategies, supervisory access, incident reporting, and equivalent monitoring on inputs and outputs. We help you build the inventory of vendor AI in your organisation, triage it against the regulatory landscape, and integrate it into the broader operating model.

Question 21

Are your training courses really free?

Accepted Answer

Yes. All eight training courses are free, self-paced, and produce certifications on completion. There is no upsell to a paid version. They exist because they are credibility infrastructure for the consulting work — leaders who take the courses understand the framework before we ever speak.

Question 22

Which course should I start with?

Accepted Answer

For COOs, CROs, and Chief Transformation Officers: AI Enablement for Operations Leaders. For CDOs, data architects, and engineering leads: Building Data Foundations for AI. For CROs, heads of compliance, and model risk leaders: AI Governance & Model Risk for Financial Services. For process improvement and operational excellence: Six Sigma Yellow Belt or BPMN Process Mapping. For change leadership: Change Management for Financial Services.

Question 23

Do certifications carry weight outside Insight Centric?

Accepted Answer

They are professional development certifications from a specialist consultancy, not industry-wide credentials. They demonstrate that you have completed structured training on the specific frameworks we use. Many of our course participants list them on LinkedIn alongside their other professional development. Whether they "count" for your specific career context depends on your industry and employer.

Question 24

Can we license your training for internal use?

Accepted Answer

Yes — bespoke training for internal teams is a separate engagement. We deliver tailored AI Enablement, operating model, and risk training programmes for COO, CRO, and CTO teams customised to your systems, regulatory context, and the operating model you are trying to build. Pricing is per-engagement based on team size and customisation.

What people ask before they engage

AI Enablement

Question not answered here?