Use this page in security, architecture, and procurement reviews before you treat AI Fabrix as an approved enterprise platform.
Purpose
AI Fabrix is evaluated as an operating model for governed Role Assistants — not as a chat product or integration bus. Confirm that structural controls match your enterprise requirements using real identity and scoped data access.
Enterprise evaluation criteria
| Dimension | What to validate | Why it matters |
|---|---|---|
| Deployment model | Platform runs in your Azure subscription / landing zone | Control plane and data boundary stay customer-operated |
| Identity | Entra ID (or wizard-configured identity) through execution | Prevents permission leakage and anonymous AI access |
| Governance | Roles, dimensions, protection, certification are enforceable | Avoids policy drift and exception paths |
| Enterprise Knowledge | Business metadata and relationships before AI context | AI reasons about customers and contracts, not raw API fields |
| Integration model | External systems via manifests; secrets in vault paths | No long-lived service accounts in integration JSON |
| Capability mediation | AI requests business capabilities, not vendor credentials | Capability gateway enforces scope |
| Auditability | Deterministic logs and evidence from completed work | Required for regulated and operational review |
| Standards | OpenAPI and Enterprise MCP as published contracts | Inspectable, portable integration surface |
| Lifecycle | Dev / test / prod promotion for integrations and policy | Production readiness without rework |
| Cost model | Azure-native infrastructure; predictable scale tiers | See Platform sizing |
Treat UI polish, prompt templates, and pre-built workers as secondary during platform evaluation.
Security and compliance checklist
Identity and access
- [ ] Enterprise identity used for human and platform admin access
- [ ] Business roles and platform developer access are separable (Platform developer access)
- [ ] RBAC and ABAC validated with scoped subject users, not global admin only
- [ ] No shared integration service accounts required for governed sync
Data access and isolation
- [ ] Data retrieval enforced in the dataplane execution boundary
- [ ] Metadata and dimensions applied before AI receives context
- [ ] Protection manifests uploaded and verified (
verify-governancepillar)
Network and operations
- [ ] Deployment fits your VNet / private endpoint standards (per your Azure design)
- [ ] Audit logs retained in customer-controlled storage
- [ ] Human-in-the-loop and approval flows supported where policy requires
Compliance alignment
- [ ] No “AI exception” paths that bypass Operational Trust
- [ ] Certification covers operations, metadata trust, and governance — not a single checkbox
Architecture review questions
Use with Platform architecture and Trust boundaries open.
| Layer | Questions |
|---|---|
| Controller (Miso) | How are policies, environments, and deployment lifecycle governed? Where is identity persisted? |
| Dataplane | Where is per-user authorization enforced? How are field mappings and dimensions applied? |
| Integrations | How are credentials resolved? Are contracts published via upload/certification? |
| Role Assistants | Can workers only invoke allowed capabilities for the active role? |
| Exit | Can integrations and evidence be exported? Is infrastructure standard Azure? |
Evaluation outcome
At the end of evaluation you should have:
- Security and architecture sign-off on the model, not a single demo script
- At least one realistic use case with scoped roles and data
- A documented path to production sizing and environments
If requirements are not met, the evaluation should show why — without sunk cost in throwaway prototypes.
Limits
Checklist items describe platform properties to verify during evaluation; they are not a substitute for your organization's security assessment, penetration testing, or contractual due diligence. Some criteria assume Entra ID and Azure-hosted deployment — adapt questions when your identity or cloud boundary differs.