Organization pilot

Pilot constraints

Dedicated organization runtime cluster
Entra OIDC required
Selected pilot Entra users/groups only
Managed source only initially
Nuxt template only
Internal apps only
No regulated data
No enterprise system integrations
No private-network access
No public apps
SQLite + KV
Approved public HTTPS destinations only
Synthetic preview data
Human production approval
Automatic backups
Full audit

Suggested pilot application

Equipment Requests remains a good proving case because it exercises:

• Form workflows
• Group-restricted access
• Business roles
• SQLite data
• Manager approval
• Notifications later
• Non-regulated workflow data
• AI-driven iteration
• Preview/deploy/rollback

Organization Entra configuration

Initial mappings:

SG-Intrnl-Pilot-Creators
→ Creator

SG-Intrnl-Pilot-Approvers
→ Approver

SG-Intrnl-Pilot-Security
→ Security Admin

SG-Intrnl-Pilot-Users
→ app consumer eligibility

Prefer assignment to the intrnl enterprise application so users cannot sign in merely because they possess an organization account.

Pilot access profile

Require:
- Organization Entra identity
- assigned pilot/application group

Optional:
- Organization Offices or VPN IP list

Pilot AI policy

Only organization-approved AI account classes.

No personal AI account may access organization source unless the organization explicitly permits it.

No regulated data may be entered into prompts, source, logs, previews, or databases.

Pilot completion scenario

An employee with no Git account and no local development environment must be able to:

1. Sign in with Entra.
2. Create an application.
3. Connect an approved AI client.
4. Ask for an equipment-request workflow.
5. Generate source in the managed repository.
6. Build successfully.
7. Open a protected preview.
8. Request changes through AI.
9. Request deployment.
10. Have an approver review the diff, capabilities, and migrations.
11. Deploy.
12. Have another organization user authenticate and use the app.
13. View a complete audit trail.
14. Roll back the application.
15. Complete a database restore drill.
16. Export source and data.
17. Reassign ownership.

Regulated data boundary

A future tier supporting regulated data is a separate undertaking. The pilot does not support regulated workloads.

Before enabling that tier, intrnl requires:

• Applicable data-protection agreements between the organization and intrnl
• Corresponding agreements with applicable subprocessors
• Approved AI vendor/configuration
• Formal risk analysis
• Data classification, redaction, and support procedures
• Incident/breach procedures
• Data retention and deletion contracts
• Access reviews
• Security evidence
• Disaster recovery commitments
• Isolation and support requirements appropriate to the workload

A dedicated cluster alone does not establish compliance. Each supported workload needs an explicit security, legal, and operational review.