How to build software in a regulated enterprise

Help more people turn ideas into software

A CTO can invite people across the organization to build prototypes with AI. Finance teams know their approval problems. Operations teams know their repeated manual tasks. Give them time and tools to show a better workflow.

Allow different tools for exploration within clear rules for installation, accounts, and permitted inputs. Provide synthetic datasets, sandbox APIs, and practical help. People should have a clear route to demonstrate value without connecting production systems.

Then define the next decision: what must be verified before the app receives confidential information, live API permissions, or production traffic? Make that route understandable to the person who built the prototype.

What changes when the prototype needs real access?

A working feature is one part of a service. The organization must also explain who can use it, how it handles data, and how it recovers. These responsibilities continue after release.

Applicable requirements depend on the service, sector, jurisdiction, contracts, and data. Ask the responsible legal, privacy, and security specialists to identify them. A development framework or vendor certificate does not establish compliance for your specific service.

The steps below provide an engineering workflow. Use them to connect requirements with decisions and evidence. NIST SSDF provides secure development practices that can support an existing SDLC. It is not a substitute for identifying applicable obligations.

1. Turn the useful prototype into a service brief

Ask its creator to describe the problem, demonstrate the workflow, and record what users learned. Keep the creator involved as a domain expert. Assign technical assessment and ongoing operation to teams with those responsibilities.

Write down the user task, intended outcome, and consequences of failure. Name the product owner, service owner, security contact, and person who can accept residual risk. Agree who can stop a release.

For example, a customer-data export needs more than a download button. Define who may export which records, for what purpose, and with what retention period. Identify who investigates an unauthorized export. This is a fictional example.

Evidence to keep: a service brief, responsibility map, and approved acceptance criteria.

Continue with requirements and traceability and service ownership.

2. Verify the boundary before granting data or API access

Identify confidential information, personal data, credentials, and other restricted material. Map where prompts, retrieved context, logs, and generated outputs go. Check the selected service’s retention, training, access, and regional processing terms.

Use synthetic or approved test data while you explore an idea. A successful prototype does not prove that its provider can process production data. Check each provider and deployment configuration.

A fictional bank dashboard built on Tuesday may work well with invented transactions. Read-only account access can still expose confidential records. Payment permissions can add financial consequences. Verify the actual scope, credential handling, authorization, and failure behavior before enabling the connection. Work through the banking prototype example.

This review must happen before the first sensitive input or live connection. Calling the app a prototype does not reduce the permissions it already holds.

Give agents only the tools and permissions required for the task. Treat repository files and retrieved documents as untrusted input. Keep secrets out of prompts.

Evidence to keep: a data-flow diagram, provider assessment, and permission policy.

Read data boundaries and agent permissions.

3. Provide a supported route into production

Place the service within the organization’s identity, network, logging, and deployment controls. Define supported environments and infrastructure as code. A container and database do not establish the full operating environment.

When policy requires your own infrastructure, verify deployment into your cloud accounts or networks. Check runtime controls separately from development and model data flows. Hosting in your account does not establish compliance or keep every AI request inside that account.

The supported route can use an internal platform, a software factory, or both. Define what each provides for verification, deployment, vulnerability fixes, and operation. A prototype may need changes or replacement code before it can use that route.

Agree the acceptable outage duration and data loss: RTO and RPO. Select availability and recovery mechanisms against those objectives. Multi-AZ, multi-region, and backups solve different failure scenarios. Test the complete recovery process, including dependencies and restored data.

Evidence to keep: an architecture decision record, environment definitions, and measured recovery results.

Study enterprise infrastructure and RTO and RPO. Then use the recovery exercise.

4. Build small changes with verifiable requirements

Give the developer or agent a clear task and acceptance criteria. Link the requirement to its implementation, tests, and review. Keep changes small enough to inspect.

Define security requirements before testing. OWASP ASVS provides requirements for application security verification. Select the relevant requirements and record their scope. A scanner result alone does not verify application behavior.

Test rejected actions as well as successful actions. In the export example, verify that an unauthorized user cannot request another customer’s records.

Evidence to keep: the requirement, change diff, test results, and review decision.

Continue with tests as evidence and reviewing AI-generated code.

5. Make the release decision reproducible

Build an identifiable artifact from the reviewed revision. Record the target environment, configuration, required checks, remaining risks, and release decision. Test the rollback or recovery method before it is needed.

Decide when human authorization is required. Keep an exception’s owner, reason, scope, and expiry date. Do not treat an approved exception as a permanent change to policy.

Evidence to keep: the artifact identity, release record, approval or policy decision, and rollback instructions.

Read release decisions and compliance evidence.

6. Maintain the software after deployment

Scan dependencies and deployed components for newly disclosed vulnerabilities. A service can become vulnerable without a new code commit. Assign each finding an owner and remediation decision.

Verify the fix, deploy it, and confirm the running version. Record accepted risks and review them again when conditions change. This ongoing work is a frequent gap when a prototype is treated as a finished product.

Evidence to keep: the component inventory, scan date, triage decision, remediation change, and deployment verification.

Follow the continuous vulnerability management workflow.

7. Operate, respond, and improve

Monitor useful service outcomes, failures, and security signals. Agree incident roles, escalation routes, and the responsibilities of the SOC and SIRT. Exercise those arrangements.

The NIST Cybersecurity Framework connects risk management with governance, protection, detection, response, and recovery. Use this lifecycle perspective when defining your operating model.

Convert incidents and recurring problems into reviewed changes. Limit self-healing to authorized actions with verification and stop conditions. An automatic restart is not evidence that the original defect is fixed.

Evidence to keep: service measures, incident records, recovery results, and verified improvement changes.

Explore incident management and bounded self-healing.

8. Decide which responsibilities to build or buy

Compare an internal platform, coding assistants, and an AI software factory against the same requirements. Ask who performs each task, what evidence is available, and what remains your responsibility. Include maintenance, recovery, integration, and exit costs.

People can keep their preferred exploration tools while the organization maintains a common route to production. Check which code, specifications, and tests transfer between tools. Require a demonstration of deployment into the required infrastructure and the full maintenance process.

Taiga publishes governance information and a shared responsibility description. Use these as one supplier’s material to assess against your requirements. Taiga publishes this learning site; these links are not independent endorsements.

Start with the responsibility comparison. The Taiga learning path then shows how these questions relate to specific product workflows.

Common questions

Can we use vibe coding in a regulated enterprise?

Yes. Give people synthetic data, sandbox APIs, and tool choice within clear organizational boundaries. Let them test ideas and bring useful prototypes to a supported delivery route. Verify controls before granting confidential data or live permissions, even before formal production. See vibe coding: uses and limits.

Does AI-generated code need different acceptance criteria?

The required behavior and risk controls still apply. AI introduces additional questions about context, data handling, permissions, and output reliability. Review the actual change and its evidence, regardless of who or what produced it.

What should we prepare first?

Prepare an exploration environment with synthetic data and a named contact for the next step. For a useful prototype, document its purpose, intended data, owners, requirements, and recovery objectives. Use the software lifecycle exercise to identify missing decisions before expanding access.