Operate AI-generated software for professional secrecy holders

Does an AI-generated application need to process client, patient or other professional secrets in production? Request a non-binding operating-model assessment.

Tools such as Lovable, Bolt, Replit and AI coding assistants shorten the path from concept to a working prototype. A visible frontend and successful login are not evidence of production readiness. That is true for all software and becomes particularly important when professional secrets are processed.

The right response is not to reject AI-generated code categorically. Treat it like acquired custom software: inventory the system, review risks, define a target architecture, make changes reproducible and assign ongoing operational ownership.

Why prototype and product are different states

A prototype normally optimises for speed:

• one person works directly against the production database
• preview and production share environment variables
• authentication works, but roles remain incomplete
• errors appear in the browser console rather than monitoring
• schema changes are performed manually
• backups exist but have not been tested
• external services were selected for convenience rather than data flow

A production system needs reproducible deployments, controlled changes, dependable authorisation and a recovery path. When professional secrets are involved, it also matters which parties and people participate in processing.

Step 1: Secure ownership and a complete inventory

Before migration, determine which components are actually available:

A code export is insufficient while data, authentication or storage remain tied to the original platform. A real exit is possible only when all runtime dependencies are understood.

Step 2: Map data flows and external services

AI assistants often add libraries and services pragmatically. Review the repository and running system for:

• analytics and telemetry SDKs
• error tracking and session replay
• external fonts, CDNs and scripts
• email, SMS and notification providers
• AI and embedding APIs
• file and image processing
• payment, signing or map services
• webhooks and automation platforms

For each service, identify which data are transmitted. An error report can include a complete request, session replay can capture form content and an AI prompt can disclose document text.

Step 3: Enforce authorisation server-side

A hidden button is not access control. Review authorisation at the server-side trust boundary:

• Can user A read user B's records through direct API calls?
• Are roles checked in the backend or only in the frontend?
• Are administrative endpoints protected separately?
• Can object identifiers be guessed or manipulated?
• Are file downloads bound to the same permissions as metadata?
• Do database policies separate tenants and roles reliably?

With Supabase, Row Level Security is a central part of this boundary. RLS still does not replace every application check: service keys, functions and server-side components may operate with different privileges.

Step 4: Separate development and production

At minimum, development and production should use separate data, secrets and deployments. Business-critical applications also benefit from staging.

This does not restrict AI-assisted development. The customer team can continue using Lovable, Bolt, Replit, a local editor or other AI coding tools. Changes are pushed to the agreed Git repository. The delivery path operated by WZ-IT automatically builds an artefact and deploys it to staging first or directly to the target environment, depending on the model. Production can require an additional review or approval.

A controlled path can look like this:

1. Review a change in the repository.
2. Run dependency checks and tests.
3. Build a reproducible artefact or container image.
4. Test the database migration against a non-production environment.
5. Approve and record the deployment.
6. Check functionality, logs and metrics after rollout.
7. Keep a rollback path for application and database.

Direct production changes complicate more than troubleshooting. They also make it unclear which code belongs to a particular data state.

Step 5: Secure application and infrastructure together

Operational responsibility does not stop at the container boundary. Depending on the application, the scope includes:

• private management access and MFA
• network segmentation and minimal public endpoints
• patching for host, platform and application
• monitoring for availability, errors, capacity and jobs
• protection against brute force, abuse and uncontrolled uploads
• backup of database, files, configuration and secrets
• a recovery test with documented results
• an incident and communications path

The OWASP ASVS and OWASP Top 10 provide structured application-review criteria. They do not replace an application-specific threat model, but offer a strong baseline.

Step 6: Align the Section 203 chain with real operations

For a Section 203 assessment, the people and providers participating in the actual production model matter. This can include managed operations, infrastructure, external support and services receiving content.

The legal scope should therefore build on the technical system model. An agreement naming only the server does not match an application that also uses external AI, email and error-tracking services. Conversely, services that receive no professional content should not automatically be described as if they process full case files.

A practical takeover path

WZ-IT typically structures takeover in four phases:

1. Inventory: capture repository, components, data flows, access and operating state.
2. Target model: define platform, isolation, identity, backups, monitoring and responsibilities.
3. Rehearsal: deploy application and data in the target environment and test user journeys and recovery.
4. Cutover: plan the switch, move production data, complete acceptance and begin operations.

The scope remains individual because a small internal workflow and a multi-tenant client portal require different reviews even when created with the same development platform.

Related WZ-IT services

• The AI Code & Production Readiness Audit provides a prioritised assessment of auth, data, security, deployment and operations before go-live or takeover.
• Prototype to Production moves MVPs from Lovable, Bolt, v0, Replit or Base44 into a maintainable production path.
• Through software development and co-development, WZ-IT can resolve findings, add integrations and continue developing the application together with the customer team.
• For professional secrets, the Section 203 Managed Cloud for AI-generated software adds the dedicated operating model to these independent services.

Sources

• German Criminal Code, Section 203
• OWASP Application Security Verification Standard
• OWASP Top 10
• Supabase documentation: Row Level Security