What percentage of enterprise AI projects fail to reach production?

Industry analyst reports consistently cite 85-95% of enterprise AI proof-of-concepts failing to reach production. Fabric Data Agent deployments show the same failure pattern unless teams take production readiness seriously — most commonly the instruction template is written without domain expert input, the feedback loop is missing, and cost attribution is not configured before scale hits.

What is the single biggest predictor of Fabric Data Agent success?

Grounding source quality — specifically, every column and measure in the grounded Fabric item having a description that matches the terminology map in the agent's instruction template. Empty descriptions are the number one source of agent hallucinations. Agents grounded on well-documented data hit 90-95% accuracy on covered question categories; agents grounded on poorly-documented data hit 60-70%.

How long does production-readying a Fabric Data Agent take?

Typically 4-8 weeks between "agent works in dev" and "agent passes the 42-item production checklist." The bulk of that time goes into grounding source cleanup (column descriptions, measure descriptions, business glossary alignment), few-shot example authoring with domain experts, and RLS testing against real user identities. Rushing this timeline is the most common cause of production incidents.

What Fabric capacity headroom should I provision for a Data Agent?

30% CU headroom above measured peak load. Measure peak-load CU consumption under representative traffic (load test at 2x forecast). Provision F-SKU capacity such that peak + 30% is comfortably below capacity. This prevents runaway agent consumption from throttling other Fabric workloads and gives cushion for usage growth.

What monitoring do I need on a production Fabric Data Agent?

Six metrics minimum: response latency (P50, P95, P99), error rate, "refused to answer" rate, CU consumption, invocation count, and user feedback (thumbs up/down + free text). All exported to Log Analytics or a Fabric warehouse. Alerts on latency P95 exceeding SLA, error rate exceeding 5%, and CU spikes. An on-call rotation must exist for business-hours pages.

What user feedback loop should a Fabric Data Agent have?

Thumbs-up/thumbs-down on every response, a free-text field for explaining wrong answers, feedback logged with full invocation context (question, answer, citation) for reproducibility. A weekly review process where the analytics team triages feedback and updates the instruction template. Instruction template updates go through a change process — test in dev, verify against a benchmark, deploy to prod. Enterprises that ship agents without this see quality decay linearly over 90 days.

Should I promote a Fabric Data Agent to production if only 30 of 42 checklist items pass?

No. That is a common "works in dev" state for agents that will fail in production. Under 28 items is a demo, not a product — do not promote. 28-34 items requires 4-6 weeks of closure work before promotion. 35-41 items is substantially ready with named owners on the unchecked items. Only 42-of-42 is a green-light for production.

How is a Power BI engagement priced for enterprise workloads?

Pricing is modeled against three variables: the complexity of the semantic layer, the volume and velocity of source data, and the governance footprint required after go-live. A scoped implementation typically runs as a fixed-fee discovery sprint followed by a time-and-materials build, because dataset refresh patterns and row-level security rules almost always evolve once real user personas review early drafts. Licensing is separated from consulting fees and mapped against Power BI Pro, Premium Per User, and Fabric capacity SKUs so finance teams can plan capacity uplift independently of delivery cost. A typical mid-market rollout lands between 120 and 480 consulting hours across data modeling, DAX optimization, report design, and deployment pipelines. Fabric workloads add capacity sizing sessions to avoid over-provisioning F-SKUs on day one.

How long does a production-ready Power BI rollout take?

A single subject-area workspace with a conformed star schema, deployment pipeline, and row-level security ships in roughly six to eight weeks once source access is granted. Multi-domain rollouts that span finance, operations, and customer analytics typically run three to five months because the semantic model has to reconcile calendar, product, and organizational hierarchies that rarely align across source systems. Fabric lakehouse projects add four to six weeks for medallion design, Direct Lake tuning, and OneLake shortcut setup. Timelines compress when an authoritative data dictionary already exists and lengthen when stakeholders are discovering definitions (for example, what counts as "active customer") for the first time. Governance, training, and center-of-excellence enablement are run in parallel rather than sequentially.

What delivery methodology do you use for Power BI and Fabric projects?

Delivery runs on a five-stage pattern: Discover, Model, Visualize, Operationalize, and Enable. Discover captures questions stakeholders actually want answered, not just source tables. Model builds a Kimball-style star schema (or a medallion lakehouse in Fabric) with conformed dimensions and documented grains. Visualize produces reports against a shared theme file, applies accessibility tokens, and uses bookmarks and field parameters instead of bespoke page duplication. Operationalize wires up deployment pipelines, dataset refresh monitoring, and Azure DevOps or GitHub source control via TMDL. Enable delivers hands-on training for citizen developers and a lightweight center-of-excellence charter. Each stage ends with a demo and a written acceptance checklist, so scope creep is visible before it becomes rework.

How do you secure sensitive data inside Power BI reports?

Security is layered rather than relying on a single control. Row-level security and object-level security are enforced inside the semantic model using DAX filter expressions driven by Entra ID group membership, so filters survive refresh and cannot be bypassed by report-level tricks. Sensitivity labels from Microsoft Purview are applied at dataset and report scope and follow exports into Excel and PDF. Workspace roles follow a least-privilege pattern (Admin, Member, Contributor, Viewer) and are granted to Entra ID groups, never individuals. Private endpoints and VNet data gateways keep on-premises sources off the public internet, and tenant-level settings restrict publish-to-web, external sharing, and guest access. Every production dataset is audited quarterly against a written RLS test plan.

Can existing Excel and Tableau reports be migrated into Power BI?

Yes, but a migration is an opportunity to redesign rather than a literal port. Excel financial models usually translate cleanly into a semantic model: named ranges become dimensions, pivot tables become matrix visuals, and SUMIFS chains become well-formed DAX measures with variables. Tableau workbooks require more interpretation because Tableau extracts and Power BI datasets have different refresh and relationship semantics; calculated fields are rewritten as DAX, LOD expressions become CALCULATE patterns, and dashboard actions are rebuilt using bookmarks and drillthrough. A discovery audit catalogs every report, ranks them by business value, and retires the long tail of duplicates before migration starts. This typically reduces the report estate by 30–50 percent.

How do you optimize DAX performance on large semantic models?

DAX performance starts with the model, not the measure. Star schemas with integer surrogate keys, single-direction relationships, and calculated columns materialized in Power Query outperform ambiguous snowflakes every time. Measures are written using variables (VAR/RETURN) to avoid repeated context transitions, and expensive patterns like FILTER over entire tables are replaced with KEEPFILTERS and Boolean filter arguments. Aggregation tables and composite models offload detail-level queries from imported caches to Direct Lake or DirectQuery sources. Every measure that appears in a production report is profiled with DAX Studio and VertiPaq Analyzer; queries above a 2-second threshold on representative hardware are rewritten before release. Fabric capacity metrics are reviewed weekly to catch runaway refreshes and interactive CPU spikes.

Do you support Microsoft Fabric, OneLake, and Direct Lake workloads?

Fabric is now the default landing zone for new analytics workloads unless a client has a specific reason to stay on legacy Power BI Premium capacity. Engagements cover medallion architecture design in lakehouses, data engineering pipelines built in Fabric notebooks or Dataflows Gen2, shortcut-based integration with Azure Data Lake Storage and Amazon S3 through OneLake, and Direct Lake semantic models that skip import refresh entirely. Capacity sizing is based on measured workload patterns rather than vendor rules of thumb, and F-SKU scaling is automated through Azure Logic Apps or the Fabric REST API so off-hours costs stay predictable. Copilot in Fabric is configured with tenant-level data boundaries and audit logging before it is enabled for end users.

What training and enablement do end users receive after go-live?

Training is tiered by persona. Report consumers get a 45-minute guided tour covering filters, bookmarks, subscriptions, and mobile access. Analysts get a three-session workshop on self-service semantic model extensions, composite models, and publishing to workspaces that follow the governance pattern. Data modelers receive a two-day immersion on star schema design, DAX fundamentals, and deployment pipeline usage. Every session is recorded, indexed, and paired with a sandbox workspace seeded with representative sample data. A written center-of-excellence charter defines who owns certified datasets, who can promote a report to production, and how to request enhancements. Office hours run for 30 days post-launch so questions do not pile up into a formal change request.

How are Power BI deployments managed across dev, test, and production?

Every production workspace is paired with matching development and test workspaces wired through Power BI deployment pipelines. Datasets are source-controlled as TMDL files in Azure DevOps or GitHub so pull requests can be reviewed by a second modeler before merge. Environment-specific parameters (connection strings, sensitivity label rules, capacity assignments) are swapped at deployment time using parameter rules rather than manual edits. Fabric deployment pipelines handle lakehouses, notebooks, and data pipelines with the same promotion pattern. Refresh schedules, gateway assignments, and alerting are applied through the Power BI REST API so they survive redeployment. A written change-management checklist covers dataset certification, dependency impact analysis, and rollback procedure for every promotion to production.

Which industries and data sources do you support most often?

Heaviest experience sits in healthcare, financial services, energy, manufacturing, and public sector, because each of those verticals pushes a different dimension of Power BI: HIPAA-bound PHI handling, transaction-grain reconciliation, time-series sensor data, cost-center-driven manufacturing variance, and FedRAMP-aligned government reporting. Source systems frequently include Microsoft Dynamics 365, SAP ECC and S/4HANA, Salesforce, Workday, Epic and Cerner (Oracle Health), Infor, and a long tail of legacy ODBC databases connected through on-premises data gateways. Fabric engagements add Azure Data Lake Storage, Snowflake, Databricks, BigQuery, and Amazon S3 through OneLake shortcuts. Regardless of source, the modeling discipline is identical: conformed dimensions, documented grains, and a semantic layer that hides the join complexity from report authors.

Fabric Data Agent Production Readiness Checklist

Analyst reports say 95% of enterprise AI projects fail to reach production. Fabric Data Agents are unlikely to be an exception unless enterprises take production readiness seriously. This checklist is what "seriously" looks like — 42 items across seven categories, informed by the failure modes that kill agent deployments before they reach a real user. Use it before you promote an agent from public preview to enterprise production. If you cannot check every box, either the agent is not ready or the checklist is telling you what to fix first.

Prerequisites

Before running this checklist, you should have:

The Fabric Data Agent API Public Preview Guide as reference for the technical concepts.
A working agent in your dev/test environment with a grounding source, instruction template, and few-shot examples.
Executive sponsor for the production deployment with the appetite to say "not yet" if the checklist reveals gaps.
4-8 weeks of budget between "agent works in dev" and "agent is production-ready" — this is not a same-day promotion.

Category 1: Grounding Source Quality (7 items)

Agent accuracy depends on the quality of the grounded data more than any other factor. A poorly documented semantic model produces a hallucinating agent no matter how good the instruction template is.

[ ] 1.1 Every column in every grounded item has a description filled in. Empty column descriptions are the single biggest source of agent hallucinations. This is non-negotiable.
[ ] 1.2 Every measure in the grounded semantic model has a description filled in. Same rule as columns.
[ ] 1.3 Business terms in column and measure descriptions match the terminology map in the agent's instruction template. If the description says "net revenue" and the map says "Total Revenue (Net)", the agent will drift.
[ ] 1.4 Data types on all grounded columns are correct. VarChar columns storing integers, decimals stored as strings, or date columns stored as strings will corrupt the agent's query generation.
[ ] 1.5 The grounded item passes the "10-question smoke test." Pick 10 questions your users will actually ask. Send them through the agent in dev. If any produce wrong answers, fix the grounding, not the instruction template.
[ ] 1.6 Row-level security has been tested against three or more distinct user identities. Confirm data isolation before production.
[ ] 1.7 The grounded item has a documented owner and refresh SLA. If the underlying data breaks or gets stale, the agent breaks silently. Someone must own it.

Category 2: Instruction Template (6 items)

The instruction template teaches the agent the domain. It's the difference between an agent that works and one that appears to work.

[ ] 2.1 Instruction template includes a business context paragraph (industry, use case, target audience) at the top.
[ ] 2.2 Terminology map covers every ambiguous business term the agent will see. Any term your users say that doesn't exactly match a column or measure name must be in the map.
[ ] 2.3 Answer format is specified explicitly. Currency format, percentage format, date format, when to include an executive summary vs a raw data answer.
[ ] 2.4 Refusal rules for out-of-scope questions are explicit. "If asked for individual customer records, respond X."
[ ] 2.5 At least 20 few-shot examples cover the top question categories. More is better; less than 10 is not production-ready.
[ ] 2.6 The instruction template has been reviewed by a domain expert who did not write it. Second pair of eyes catches business-term mistakes that the author is blind to.

Category 3: Authentication and Security (7 items)

[ ] 3.1 Authentication pattern is chosen explicitly (on-behalf-of, service principal, or managed identity) and documented in the agent's operations runbook.
[ ] 3.2 If OBO is used, token exchange has been tested with production-parity user identities — not just the developer's account.
[ ] 3.3 Service principal (if used) has the minimum required Fabric permissions. No "Contributor" or higher.
[ ] 3.4 Row-level security has been verified to fire under the chosen auth pattern. Confirm the agent cannot return data the caller can't see.
[ ] 3.5 Object-level security on warehouse columns has been tested. Confirm sensitive columns are unreachable via the agent.
[ ] 3.6 The agent's Fabric permissions are documented for compliance audit.
[ ] 3.7 Log-forwarding endpoint (Log Analytics, Sentinel, etc.) is configured to capture agent invocations for audit. Every query, every answer, every citation.

Category 4: Cost and Capacity (6 items)

[ ] 4.1 Peak-load CU consumption has been measured under representative traffic. Load test at 2x peak forecast.
[ ] 4.2 Fabric capacity has 30% CU headroom above measured peak load. Prevents runaway agent consumption from throttling other workloads.
[ ] 4.3 Per-agent CU quota is set (Fabric admin center) so a runaway consumer app cannot starve the capacity. GA only; N/A in current preview.
[ ] 4.4 Cost attribution tags on the agent are configured so agent costs show up in the right internal charge-back bucket.
[ ] 4.5 Fallback path is defined for when the agent hits CU throttling. Return a graceful "system busy, try in 30 seconds" response, not a stack trace.
[ ] 4.6 Estimated monthly CU cost is documented and approved by the budget owner.

Category 5: Monitoring and Alerting (6 items)

[ ] 5.1 Response latency P50, P95, and P99 metrics are captured to Log Analytics or a Fabric warehouse.
[ ] 5.2 Error rate metric (agent invocations that returned an error) is captured.
[ ] 5.3 "Refused to answer" rate metric is captured (the agent invoked its own refusal rule). Sudden increase indicates a data source problem or instruction template drift.
[ ] 5.4 Alerts fire on: response latency P95 exceeding SLA, error rate exceeding 5%, CU consumption spiking above baseline. Alerts go to a monitored channel.
[ ] 5.5 An on-call rotation exists for the agent. Someone gets paged when alerts fire during business hours.
[ ] 5.6 A weekly quality review dashboard is deployed showing usage, error rate, top questions, and top failure patterns.

Category 6: User Feedback and Quality Loop (5 items)

The single biggest lever on long-term agent quality is a working feedback loop. Enterprises that ship agents without this see quality decay linearly over 90 days.

[ ] 6.1 The client app implements a thumbs-up/thumbs-down mechanism on every agent response.
[ ] 6.2 A free-text feedback field is available for users to explain why a response was wrong.
[ ] 6.3 Feedback is logged with the full invocation context (question, answer, citation) so the analytics team can reproduce issues.
[ ] 6.4 A weekly review process is defined for the analytics team to triage feedback and update the instruction template.
[ ] 6.5 Instruction template updates go through a change process (test in dev, verify against a benchmark, deploy to prod). No cowboy edits on the live agent.

Category 7: Failure Modes and Graceful Degradation (5 items)

[ ] 7.1 The agent's behavior when the grounded item is unavailable has been tested and defined. Typical: return a "temporarily unavailable" response with an ETA.
[ ] 7.2 The agent's behavior when the LLM upstream is unavailable has been tested. Typical: return a "AI service unavailable, please try in 5 minutes."
[ ] 7.3 The agent's behavior on rate limiting is tested. Confirm the client app handles 429 responses gracefully.
[ ] 7.4 The agent's behavior on ambiguous questions is tested. Confirm it asks a clarifying question rather than guessing.
[ ] 7.5 A runbook exists for the top-5 failure modes with resolution steps for each.

Scoring

42 of 42 checked: production-ready. Proceed with the promotion.
35-41 checked: substantially ready. Fix the unchecked items before promotion; identify who owns each and set a fix-by date.
28-34 checked: not ready. This is a common state for agents that "work in dev." Spend the 4-6 weeks it takes to close the gap. Skipping the checklist is how projects join the 95% failure rate.
Under 28 checked: the agent is a demo, not a product. Do not promote. Revisit whether the agent is the right architecture for the use case.

What Kills Enterprise Data Agent Deployments

Recurring failure patterns from failed enterprise agent projects:

Instruction template written by developer, not domain expert. The map maps ambiguous business terms wrong. Agent looks like it works in dev because the developer is a lenient tester. Real users spot the errors immediately.
No feedback loop. Quality decays over 90 days as data changes and users ask new question categories not covered by few-shot examples.
No cost attribution. Agent consumption grows unnoticed. Finance flags a Fabric capacity budget breach in month 6 and cancels the project.
RLS not tested against real user identities. Agent leaks data on day one. Compliance kills the project.
No governance council. Nobody owns the instruction template. Every business unit lobbies for their special-case rules. Template grows to 40 pages and quality collapses.

Related Guides

Ready to run this checklist on your Data Agent before promoting to production? Book a 30-minute readiness review and we will score your specific agent across all 42 items.