AI Admin Console: what each of the six capabilities actually does
AI Admin Console exposes six capabilities. Each is a side-menu item, and each answers one specific question a procurement reviewer or compliance lead will ask during enterprise diligence. The six together cover what the EU AI Act calls deployer obligations [1] and what NIST AI RMF calls "records of system actions sufficient to reconstruct decisions" [2] — from a single desktop application the IT team already knows how to install.
The capabilities are listed in the order they appear in the Console's side menu. Each section below names the procurement question, what the Console does about it, and where the data lives.
Members & access
The question: who in our organisation is allowed to use AI Suite, and on what licence tier?
The Console lets an administrator invite teammates by email, assign Personal or Commercial licence seats (Monthly, Annual, or One-Time), and revoke access when staff leave. Bulk-invite from a CSV. The roster is the deployer's single source of truth for "who has access" — the same answer the compliance team produces when asked to demonstrate human oversight.
What lives on the Software Tailor backend: the org roster. What does not: any record of what those members did inside the model. The Console is the access surface; the inference happens locally.
Licenses
The question: what tier does each member have, and how is it enforced offline?
Per-user licence keys validate offline. Useful when seats need to keep working without a network round-trip — a common requirement for regulated industries where the AI workstation is on a segmented network. The Console issues and revokes keys; tier overrides per user are visible alongside the org default.
This is the only capability where the Console writes a value that must travel to the user's machine. Everything else is metadata about the deployment, not about the content.
AI Server enrolment
The question: what hardware is our organisation trusting to run inference?
AI Suite installs talk to a local aisuite-server process; that process can talk either to an on-device model or to a customer-controlled AI Server running inside the customer's network. AI Server enrolment is how the Console binds those server instances to the organisation so they accept signed requests from approved AI Suite installs. Pair, rotate credentials, revoke without touching the server box itself.
The procurement angle: the inference hardware is the deployer's. Enrolment proves it. The Console never sees the model's input or output.
Policy
The question: what models, providers, and data-handling rules apply to our organisation's AI Suite installs?
Policy is the org-wide configuration every AI Suite app honours: which models are allowed, data-residency hints, sign-in providers, and the OIDC tenant configuration. Changes propagate to every install at next launch. This is what the deployer points compliance at when asked "what guard-rails are in place?" — and what they edit when an EU AI Act amendment lands (most recently, the 7 May 2026 omnibus agreement tightened the high-risk system definition [1]).
Audit
The question: what happened, when, by whom — and can we produce that on demand?
Every administrative action lands in a JSONL audit row: timestamp, actor's email, action verb, affected resource, the X-App-Id of the originating client. No prompts. No responses. No document content. The deployer's content store keeps the inference content; the Console's audit row keeps the proof an action happened.
That separation is what makes the row satisfy NIST AI RMF's "records of system actions sufficient to reconstruct decisions" [2] without retaining model content the deployer doesn't want to retain. The architecture and the row format are documented in our content-free audit logs article.
Per-org usage
The question: what's actually happening across our organisation, in aggregate?
A read-only telemetry roll-up scoped to the org: active installs, top events, average inference duration, model ratings. No raw prompts. Everything is aggregated and content-free by design. The deployer's IT team uses this for capacity planning; their compliance team uses it for "is the policy actually being honoured?"
This is the only place a number that crosses members appears, and the only place the Console summarises behaviour over time.
Why a single tool
NIST AI RMF [2] asks for "records of system actions sufficient to reconstruct decisions". The EU AI Act asks deployers to demonstrate human oversight, monitor system operation, keep logs, and produce them on request [1]. In both frameworks the deployer — not the vendor — owns the obligation. The Console exists because the deployer's IT team needs one place to discharge it.
The six capabilities are not a feature checklist. They are the answer to the six questions a procurement reviewer will ask in sequence. Teams starting that diligence pass on an on-prem AI deployment should begin with the framing in Why on-prem AI deployments stall in procurement; the Console is where the answers live.
References
- European Commission. "AI Act — Regulatory framework on AI." digital-strategy.ec.europa.eu/en/policies/regulatory-framework-ai. Accessed 2026-07-01.
- NIST. "AI Risk Management Framework." nist.gov/itl/ai-risk-management-framework. Accessed 2026-07-01.
Related articles
See AI Admin Console running against a real workload.
A free 1-week pilot puts the model on the customer's hardware, the audit row in the customer's SIEM, and the Console's six capabilities into the IT team's hands.