Who we are and what we do
NTT DATA AIVista builds, delivers, and supports the agentic AI platform that NTT DATA brings to regulated industries (e.g., insurance). Unlike a startup that simply ships a chatbot and calls it done, our customers face a much different deployment cycle. Every agent that touches a claim, a policy, or a filing must answer to an underwriter’s manager, a compliance team, and eventually a regulator. “AI decided” will never be an acceptable answer.
That same constraint shaped the platform we sell and how we built it. Our engineering organization uses AI agents to write a meaningful share of our own code, and we hold ourselves to the same standard we ask of our customers: Every material decision has a person’s name on it, and every line of shipped code can be traced back to why it exists.
The Catalyst
Speed is usually the main focus when somebody adopts an AI-native software development lifecycle (SDLC). At NTT DATA AIVista, we believe auditability is just as important. In a regulated industry, we cannot go to an auditor or regulator and say, “This piece of the system is structured this way because that’s how AI implemented it.”
Our customers expect the same operational and documentation rigor they have experienced with traditionally developed software, and increasingly, regulators are writing these expectations into rules. The National Association of Insurance Commissioners (NAIC) has set the standard for insurance regulation in the U.S. for more than a century. Recent bulletins that have been adopted [1] or are in the process of being approved [2] call for clear documentation of AI systems and their lifecycles, “including design, development, validation, implementation (both systems and business), use, ongoing monitoring, updating, and retirement.” The Monetary Authority of Singapore (MAS), which regulates Singapore’s financial institutions (FIs), recently published guidance stating that “An FI should establish and maintain an accurate and up-to-date inventory of AI use cases, systems, or models across the FI to support governance and oversight, as well as risk management, throughout the AI lifecycle.” [3]
Figure 1. Why auditability, not speed, set the design constraint.
To address this, we looked at how we previously built systems and where we could leverage AI to accelerate or, ideally, automate some of the work while maintaining what we call the chain of intent. As a newly formed organization, we were starting from scratch, so we had a golden opportunity to rethink how we would develop software from the ground up and form an AI-native SDLC. The most important point of agreement was that human control is critical, and we could not leave ourselves vulnerable to the mercy of whatever an AI model chose. This is still software engineering: a discipline with human judgment at the center. Agents can do more of the work, but people must remain responsible for the intent and approval behind it.
Our Process
Most software-development methods produce similar sets of artifacts: product requirements, system designs, code, and the completed software product. Sometimes these are formally documented, while at other times they are informal or exist only in the mind of the person doing the work.
Figure 2. The artifacts every system leaves behind — and the loop production closes.
Agents can only reliably follow explicit intent, so informal artifacts weren’t an option for us. We formalized the artifacts and changed their roles: requirements and designs became human-approved sources of truth for the intent of the system, and they govern agent execution.
Chain of Intent
We treat the product requirements document (PRD) and design specification as human-approved sources of truth. Agents help draft both, but people supply the judgment and approval that make them authoritative. Once approved, those specs govern the agent’s implementation and testing, and once a person signs off, the code gets packaged with the specs into a deployable bundle.
None of that starts with a blank page. Every PRD can be traced back to a customer conversation, a field observation, or a support ticket. That discovery work stays informal. What we formalized is the handoff: The PRD is the first point where that judgment must become explicit enough for an agent to build against and specific enough for a person to be accountable for it. Spec-driven development (SDD) usually starts with a design or implementation spec. Our chain of intent starts one step earlier, at the PRD, because that is where informal intent first becomes a governed artifact.
Figure 3. The chain of intent: who decides, who executes, and what travels with the code.
The runtime bundle is the key deliverable of the process, containing the application code as well as the requirements and designs. Each bundle is versioned the way you would typically version releases. If an auditor ever asks why a system behaves in a particular way, we can easily answer that using information from the runtime bundle that was deployed and running in the environment. The requirements in the bundle explain the why. The design spec and code explain the how.
Bundling the specs with the code creates the chain between a person’s intent for how the system should perform and the final delivered software product. Our principle is to never touch code first. We work backward through the process and make the change in the appropriate spec. Instead of a historical implementation artifact (that can drift) the spec in SDD becomes something that represents the current intent of the system as well as the decisions made up to that point.
The chain is completed by the links in each phase. A design spec references the exact requirements it is satisfying with a given component or implementation, and tests are annotated with the requirements they are verifying. Any approved change to a spec propagates down the chain with the help of agents.
Governance in Execution
Following SDD during execution means the agent verifies its changes align with the specs – but that wasn’t enough for us. We added tests for our documents, just like you would write tests for code. Our design documents are tested to confirm they reference an actual PRD and real requirements from that PRD. Similar checks are done for the unit and integration tests where we ensure that classes and functions are annotated with real requirements from the PRD. Over the past three months, automated reviews blocked 54 out of 678 PRs due to unreferenced specs.
We also added domain-specific checks using deterministic hooks and reviews that must pass before a person reviews the code. Making these deterministic gives us repeatable evidence that we are satisfying regulatory and security requirements. For example, we have a hook that scans all log statements for attributes or objects containing attributes that have been annotated as PII; we don’t use regexes for this. This safeguard ensures we don’t expose nonpublic information through logs under the Insurance Data Security Model Law. These checks are included in the runtime bundle, so they are both our implementation guardrails and our evidence to auditors.
Figure 4. Deterministic checks run before a person ever opens the pull request.
Revised Process, Revised Roles
Our approach to SDD also allowed us to revisit technical roles within the organization. Traditionally, roles fell under certain archetypes, such as product manager, architect, designer, and software/dev ops engineer. Each role typically stays in a particular lane with handoffs and context switching. We have carefully and deliberately blurred these boundaries at AIVista.
Our technical staff has a primary discipline (product, engineering, or science), but each person contributes across the SDLC, not just within their lane. Product leads have taken their own requirements and shipped UI changes after engineer code review. Engineering leads have written product requirements, reviewed them with product leads, and shipped the feature themselves. Over the past three months, about 30% of our PRDs were originally drafted by an engineering specialist.
Figure 5. Traditional lanes, and how contribution actually flows at AIVista.
Conclusion
Agents can execute more of the lifecycle, but they do not own product judgment or accountability – people do. Our SDLC emphasizes that. Software starts with a person’s intent, captured in an authoritative spec, chained all the way to implementation, so every piece of delivered software can trace its lineage back to that intent.
