The dashboard looks fine. The territory math does not.
A brand team can sit in a quarterly review and never notice the break. Product shares inside one territory add up to 112 percent. A healthcare professional ID is missing a digit. A switch rate sits outside any range a medical lead would defend in a live meeting. Nothing crashes. The pipeline stays green, the chart still renders, and the next AI pilot inherits the mess.
That is the failure Indegene is aiming at with a production Data Quality Agent inside its NEXT Unified Data Platform. Indegene, a life-sciences commercialization company that works with pharmaceutical, emerging biotech, and medical-device companies, describes the design with AWS in the technical post “How Indegene is modernizing and scaling enterprise data quality in life sciences, ” co-written with Shravan K S of Indegene. Nobody is claiming the model suddenly understands medicine. The real constraint is writing, testing, and maintaining data rules for every commercial, medical, and clinical analytics program that claims to be ready for AI agents.
Why the old quality program cannot keep up
Life-sciences companies are spreading enterprise AI across commercial, medical, market access, and adjacent teams. Those models and dashboards are only as trustworthy as the tables underneath them. The data is scattered across platforms, pipelines, and owners. Technical teams hold the checks for nulls, types, and duplicates. Business teams hold the logic for affiliation, segmentation, eligibility, territory alignment, and product hierarchies. The two rarely live in the same system.
Static validation is a poor fit for that second list. A column that is merely “not empty” will accept a broken identifier. In the United States, a National Provider Identifier is a 10-digit number, and a serious check also validates it against a reference, not just a character count. Market share has to total 100 percent within a territory, and no single share inside that territory should exceed 100 percent. Those are business rules. They look obvious in a meeting. They get fragile the moment someone copies them into five tools by hand.
Indegene’s point is a fair one. Quality belongs inside the data platform, next to metadata, lineage, governance, and analytics. A disconnected quality tool just becomes another place for rules to drift.
What the agent is actually for
As Indegene and AWS describe it, NEXT UDP hosts standalone AI agents for data ingestion, data quality, orchestration, cataloging, and SQL generation, with room to customize how those agents talk to each other. The Data Quality Agent is the one that profiles a table, recommends rules, and drafts the code. The published design runs it on AWS, using Amazon Bedrock, the Strands Agents framework, and Amazon Bedrock AgentCore. The post names Claude Sonnet 4.5 in the generation layer and says other Bedrock foundation models are supported.
It can connect to Amazon Redshift, Snowflake, Amazon S3, and JDBC or ODBC sources. Recommendations are meant to be grounded, not free-associated. Retrieval pulls from an internal enterprise knowledge base (glossaries, data dictionaries, standard operating procedures, regulatory guidance, approved rules, prior scripts, profiles, anomalies, and feedback from subject-matter experts) and from an external reference base of standards and validation practices. Profiling and anomaly detection supply the evidence from the table itself. Reviewer feedback is retained so later suggestions can improve.
Think of it as a very fast junior analyst with a library card. It can draft. It should not sign work that can turn a bad commercial or medical number into a bad decision.
Rules come in three modes. Column-level checks cover one field: nulls, types, ranges, formats, uniqueness. Table-level checks cover relationships. That is where a healthcare professional (HCP) product-performance table gets interesting: professional, specialty, territory, product, prescription volume, market share, switch rate, rating, reporting month. Custom-query mode turns a plain-language constraint into SQL. Generated code can be SQL, Python, or PySpark. Before it is treated as usable, the design calls for a syntax check, a check against the target schema, and a sample-data test run where the language supports it.
A second model pass, described as a Validation Agent, reviews the generated rules. That is a sensible second look. It is not an independent check if it shares the same schema, prompts, and failure modes as the first pass. And it is not proof the first look was right.
The design choice that actually matters
Popular demos imply the agent will run the quality program. This one is built to refuse that job where the rule encodes a business judgment.
The post tags rules Critical, Basic, Complex, or Information, a mix of severity and complexity that it never fully maps to an approval path. What it does say is narrower. Only high-confidence, low-risk rules are approved automatically. Critical rules and business rules always go to a subject-matter expert. Every decision is recorded. The numeric bar for “high confidence” and “low risk” is not published, and neither is how often automatic approval actually fires. That missing threshold is the control design. Do not file it as a footnote. A tag such as Basic is not, on the published description, a free pass.
The account is also thinner on how external reference material is approved, refreshed, and audited, and on what happens when an outside standard conflicts with an internal procedure. Those gaps matter as much as the model name.
Security language needs the same discipline. AWS documents Amazon Bedrock AgentCore (the managed agent platform in this design) as HIPAA eligible, and as covered by SOC 2, CSA STAR, FedRAMP Class C and Class D, and a specified set of ISO standards. Those are AWS’s program listings. They are not a customer certificate. The documentation does not put GDPR on that list. AWS also describes internal assessments of AgentCore against a longer set of regional and industry programs, with third-party review expected in later cycles. Internal alignment is not a certificate, and service eligibility is not a compliant deployment. Under AWS’s shared-responsibility model, what a company may do with healthcare data still depends on its configuration, its data, and the law that applies to it.
The speed claims, labeled as what they are
Indegene’s effort figures come from its own production deployments of NEXT UDP, at enterprise scale (on the order of 25 to 50 schemas, 500 to 2, 000 tables, and a central store of 1, 000 to 10, 000 rules). They are estimates. No independent audit, sample size, timeframe, or baseline method is published with them. Read them as a vendor’s operating report. They are not a settled benchmark.
Within that frame, the shift Indegene highlights is large. Rule work is estimated at about 30 hours down to about 4 hours per dataset. That is the cut it frames as roughly 85 percent less effort, or about seven times the productivity. New-table onboarding is a different estimate: 2 to 4 hours instead of 2 to 5 working days. A third figure, 50 percent faster onboarding for a new dataset in a domain the platform already knows, is a much smaller cut of a narrower job. Do not average them, and do not add them.
Indegene also reports other cuts: manual SQL authoring, token cost on cached prompts, compute from a metadata-first profiling approach, and various discovery and maintenance steps. Those estimates overlap. They describe related work. You cannot stack them as separate wins. Less effort to maintain the rule book is not the same as less governance. If the override log gets thinner because people stopped reading, the productivity chart will still look wonderful.
Vendor timings for profiling, rule generation, and execution sit in seconds to a few minutes. A stopwatch is a poor proxy for a steward’s judgment. The figure worth circling is acceptance. Indegene puts rules accepted without changes at 60 to 75 percent. That means a quarter to two-fifths of suggestions (25 to 40 percent) still need a human edit or an override.
The hallucination line is the softest of the set. Indegene describes a rate of less than 5 to 8 percent, meaning references to columns that do not exist or business logic that is simply wrong. The range is written loosely, and no scoring method is published. Treat it as a warning light with an unclear calibration. It is not a quality certificate.
What these estimates do not show is the outcome a chief commercial officer or a safety lead would actually fund: fewer compliance incidents, better territory decisions, lower risk from a bad number reaching a decision. No named customer case is attached. Planned additions (AI-assisted remediation and root-cause analysis of recurring anomalies) are proposals. They are not reported capabilities.
Questions worth asking before you copy the pattern
- Does this kind of AI agent replace the data steward?
No. The published design keeps critical and business rules with a human, records every decision, and treats the model as a drafter. That automates the typing. The signature still belongs to a person.
- How much faster is the work, on Indegene’s numbers?
Indegene estimates about 30 hours down to about 4 hours per dataset, and new-table onboarding in 2 to 4 hours instead of 2 to 5 working days. A separate, smaller claim (50 percent faster onboarding when the domain is already known) measures a different job. These are overlapping company estimates, not an independent study, and they do not add up to one speedup.
- If most suggestions are accepted, why keep a reviewer?
Because 25 to 40 percent still need a change, and the checks that encode commercial or medical logic are exactly the ones barred from automatic approval.
- Can the model invent a column and sound sure of itself?
Yes. Indegene’s own estimate puts that class of error under a loosely stated band of less than 5 to 8 percent, with no public scoring method. Schema checks and a second model review reduce the risk. They do not erase it, especially if the second pass shares the first pass’s inputs.
- What is the bar for automatic approval?
Unpublished. Only high-confidence, low-risk rules may pass without a person, and the post never defines those terms as numbers or says how often that path fires. Critical rules and business rules always go to a subject-matter expert. A label such as Basic is not defined as a free pass.
- Does running this on AWS make the deployment HIPAA-ready?
No. AWS documents AgentCore as HIPAA eligible, among other program listings. Eligibility of a service does not certify your configuration, your prompts, or your life-sciences validation package.
- What should a business leader measure if engineering effort is not the point?
Acceptance versus override, the share of rules that touch commercial or medical logic, and whether bad records stop reaching the decisions those teams make. The published evidence does not yet answer that last question.
Steal the operating model, not the victory lap
For AI in business, the useful pattern here is narrower than the headline and more valuable because of that. Put AI agents where the work is repetitive, grounded in documents you already trust, and easy to test: profile the table, propose the technical check, draft the SQL, adapt a rule you have already approved. Keep a human on anything that encodes how a market, a product hierarchy, or an eligible customer is supposed to behave. Version the rule. Keep the override.
Commercial and field teams should care for a practical reason. Territory share, prescriber identity, and product performance are sales operations data wearing a clinical vocabulary. An agent that helps stewards catch a share total that cannot exist is AI for sales only in the unglamorous sense: it stops a bad number from becoming a bad call. That is a better use of the technology than another dashboard that narrates the same unchecked table in smoother prose.
The companies that get this right will let the agent do the drafting and keep the right to say no. Speed without a recorded override is just a faster way to standardize a mistake.