The real procurement question: can we operate this responsibly?
Enterprise AI buying decisions often begin with model capability and a product demonstration. For regulated organizations, that is not enough.
A credible deployment must show how information moves, who can see it, how permissions are enforced, what happens when a component fails and who is accountable for each control.
The same questions apply whether the chosen architecture is hosted, private cloud, hybrid or on-premises. This checklist is written for CIOs, CISOs, chief risk officers, legal teams and procurement leaders evaluating a private AI platform.
It is not a certification or legal opinion. It is a way to turn broad claims such as secure, private and compliant into evidence requests that can be tested before production use.
Data and Architecture
What is the complete data boundary?
Ask for a diagram covering source documents, prompts, retrieved passages, embeddings, model outputs, logs, diagnostic bundles and backups. Identify storage location, retention and every external connection. A statement that the model runs locally does not describe the entire processing chain.
Where is inference performed?
Establish whether the model executes in the customer-controlled environment or calls an external provider. Confirm whether identity, update, certificate or separately approved integrations can create cross-border flows. Review applicable contracts for the actual deployment location.
Who determines controller and processor responsibilities?
A local appliance does not itself assign legal roles. The parties should define processing purposes, instructions, support access and responsibilities in their agreements and applicable data-processing terms, with the customer's legal team.
What happens to data when the relationship ends?
Ask how exports, deletion, backups, logs, credentials and physical media are handled. Test whether the organization can retain its knowledge and migrate workloads without losing operational control.
Identity and Security
Are permissions enforced on the server?
User-interface restrictions alone are insufficient. Test role-based access, knowledge-base and document ACLs, and re-authorization of retrieved passages. Include negative tests where a user attempts to retrieve another team's information.
What privileged access exists?
Inventory administrator, database, service and support privileges. Require least privilege, approvals, separation of duties and reviewable evidence. Validate password protection, throttling, credential rotation and emergency-access procedures.
What can vendor engineers see?
Ask whether routine telemetry or remote support is built in, whether diagnostics are sanitized and whether access to customer systems or content requires separate approval. SANCTUM's described appliance has no built-in routine vendor telemetry or remote-support channel; administrators may collect sanitized diagnostics, and engineer access must be separately authorized and governed by the customer's process and agreement.
How are backups and recovery secured?
Verify encryption, key custody, backup access, restore testing, recovery objectives and isolation. A private deployment can still be exposed through unprotected backups or overly broad privileged roles. Ask for evidence rather than assuming controls are complete.
Governance and Operations
What is actually audited?
Request the current event inventory, retention, integrity protections, export formats and coverage gaps. Test whether the logs can reconstruct an incident. Do not equate an audit feature with complete, immutable evidence or a certified compliance outcome.
Who approves model and prompt changes?
Establish release management, evaluation datasets, rollback, versioning and the owners of prompts, indexes and workflow rules. A model upgrade can change answer behavior even when the interface looks identical.
Where is human oversight mandatory?
Define use cases where AI may retrieve or draft, and those where an authorized person must review, approve or act. Make escalation visible in the workflow and test how the system handles uncertainty or missing sources.
What does the vendor contract actually promise?
Align product claims with service levels, support access, incident notification, retention, subprocessor or integration terms, security responsibilities and exit assistance. Compliance is a shared implementation and governance exercise, not an automatic feature of installing software.
Product positioning is not a substitute for verification.
SANCTUM presents private AI infrastructure for organizations that want AI to work with approved enterprise knowledge inside a selected environment. Its three operating pillars can be understood as Intelligence, Security and Operations.
Intelligence includes local chat, hybrid RAG, OCR and document analysis. Security includes identity, roles, ACLs and audit. Operations includes health, model management, release deployment, backup and recovery.
Its site describes knowledge assistants, document intelligence, compliance-related assistance and controlled workflow support. These capabilities are relevant to the checklist, but product positioning is not a substitute for verification.
The supplied technical reference identifies gaps including a superuser database role, absent password throttling, unencrypted backups and incomplete audit coverage. Those items should be assessed and remediated before a customer treats the relevant controls as production-ready. Security controls reduce exposure; no platform guarantees breach prevention.
Turn due diligence into an acceptance plan.
Create a joint evidence register. For every claim, record the responsible party, current status, evidence artifact, test method, residual risk and sign-off. Classify gaps as blockers, mitigations or accepted risks. Include technical testing, contractual review and an operational rehearsal.
A board-level summary can then show which business use case is being enabled, which risks are controlled, which remain open and what decision is requested.
For a first rollout, use one bounded workflow and a small authorized user group. Test data residency, retrieval permissions, prompt injection resistance, source quality, logging, backup restoration and support authorization. Repeat the tests after material changes. This creates a stronger path from pilot to production than treating procurement as a single security questionnaire.
Does private AI automatically make us GDPR-compliant?
No. Private AI can support certain data-protection requirements, but compliance depends on validated technical controls, organizational procedures, contractual responsibilities and the specific processing activity.
Does local processing guarantee there is no cross-border transfer?
No. The physical location of the primary AI system is only one part of the assessment. Identity services, software updates, certificate services, integrations, diagnostics and other reachable external services should also be reviewed.
Is an audit feature the same as complete audit evidence?
No. Organizations should verify audit coverage, integrity, retention and exportability, then test whether the available records can reconstruct relevant security or operational events.
Can our engineers operate the system?
That should be established through documented ownership, training, access controls, release procedures, backup processes and recovery testing. Operational capability should be demonstrated rather than assumed.