Maritza Diaz, Chief Executive Officer at ITJ.gettyOver the last several years, I've worked with engineering teams building software for life sciences companies. One of the most frustrating patterns that I've noticed is when a team validates an AI feature in development, only to discover that passing model validation and passing a regulatory audit are two very different milestones.Imagine a company launching an AI-powered clinical workflow tool. The model meets its performance targets and receives approval to move forward, only for an FDA audit to find that its documentation chain doesn't meet 21 CFR Part 11 expectations. This scenario is becoming increasingly common as AI moves from experimentation into regulated healthcare environments.​The Compliance Gap​AI adoption is accelerating across life sciences, from clinical workflows to quality systems and manufacturing operations.The challenge is that many of the tools enabling this transformation were originally built for commercial software environments, where speed often matters more than accountability, rather than for regulated ones.That distinction becomes critical when AI influences decisions that affect patients, product quality, manufacturing records or regulatory submissions.In my experience, the underlying technology and the engineering teams are not the root of most compliance failures. Instead, life sciences companies often adopt AI infrastructure designed for flexibility and scale without fully considering the traceability, auditability and change-control requirements that regulated environments demand.As regulators develop more explicit guidance for AI-enabled systems, that gap is becoming harder to ignore. For example, the FDA's guidance on AI-enabled device software functions emphasizes life cycle management, transparency and documentation, while the EU's AI Act imposes similar scrutiny on high-risk AI systems globally.Regulators remain focused on accountability for AI-generated outputs, regardless of the underlying technology.​Why Traditional Software Thinking Doesn't TranslateAlong the same lines, I often see teams treating AI validation like traditional software quality assurance. That approach worked when software behavior was deterministic, meaning a given input produced a given output, traceable directly to code changes. AI systems behave differently: models drift, data changes and performance can shift even without new code.I've spoken with teams that assumed completing validation before launch would be sufficient to satisfy future audits. What often surprises them is that regulators are just as interested in how a model behaves after deployment as they are in how it performed during testing. The AI requires post-market monitoring, for example.Even if a model works at first, an organization must be able to continuously demonstrate control over it. That's a fundamentally different engineering challenge.​​What Compliant AI Actually RequiresIn practice, four capabilities separate audit-ready systems from those that struggle under regulatory scrutiny.The first is end-to-end traceability. Every meaningful output should be linked to its source data, model version, validation records and deployment configuration. When auditors ask how a recommendation was produced, teams should be able to answer without reconstructing events manually.The second is controlled model evolution. The FDA's Predetermined Change Control Plan (PCCP) framework requires companies to think about future model changes before they happen: how retraining will be managed, what modifications are allowed, who approves them and how those changes will be validated.Human oversight matters, too: AI can't operate as a black box in regulated workflows. Clinicians, quality engineers and regulators need visibility into how systems reach conclusions.Finally, there is performance transparency. Teams often focus on accuracy while overlooking the importance of communicating limitations. Structured documentation, such as model cards, helps capture training data characteristics, performance metrics, known constraints and population-specific considerations.​Where Engineering Teams Commonly MiscalculateWhen compliance issues emerge, they're rarely caused by a single catastrophic decision. More often, they're the result of several reasonable decisions made independently across different departments.One common example is organizational separation: Data science teams build models, engineering builds systems, quality handles compliance and regulatory prepares submissions. Each may be doing its job well, but they won't help if they don't decide together until after major architectural choices have already been made.I've seen companies discover late in development that the platform they selected cannot easily support the documentation chain regulators expect. At that stage, remediation becomes significantly more expensive than building the right foundation from the start.Another common misconception is assuming that a functional AI feature is automatically a submittable one. A model may perform exceptionally well and still lack the evidence package necessary to support regulatory review.​A Practical Framework For Technical LeadersWith these challenges in mind, there are a few steps teams can take to help ensure they build with regulatory compliance from the outset:​1. Architect for compliance early. Traceability, authentication, audit trails and documentation requirements should be embedded during the architecture phase, not added after the MVP has already been built. Retrofitting compliance is almost always more expensive than designing for it.​2. Create cross-functional governance early. Engineering, R&D, quality and regulatory teams should share responsibility for AI decisions from the beginning.​3. Document the life cycle, not just the outcome. It is crucial to maintain visibility into training datasets, validation processes, monitoring strategies, performance trends and drift-management plans. In regulated contexts, the history of a model often matters just as much as its current performance.​4. Invest in people who understand both worlds. Early in conversations with healthcare technology leaders, I often hear questions about which AI platform or tool they should adopt. In my view, that's the wrong place to start. Technology choices matter, but people matter more. By having engineers who understand both software development and regulatory frameworks such as IEC 62304 and ISO 13485, your team will have a better understanding of why documentation is part of the engineering process itself.​The Opportunity Inside The ConstraintWe spend a lot of time debating whether today's AI tools are ready for regulated healthcare, but the more important question is whether organizations are building the teams, processes and governance needed to support those tools once they leave the lab.Success rarely comes down to having the most sophisticated model, but from establishing the accountability, traceability and operational discipline to support that model over time.Innovation remains essential, but in life sciences, trust is what ultimately drives adoption.​​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?