Quant AI Transparency Statement

Purpose of this statement

This statement describes how Quant's AI services operate. It is published so that customers — including Australian Government agencies subject to the Policy for the responsible use of AI in government (DTA, v2.0) — can understand and reference how Quant processes information when AI features are used.

This is a vendor transparency statement. It is not a substitute for the transparency statement an Australian Government agency must publish about its own AI use. It is intended as a reference artefact that agencies can cite when describing their use of Quant AI services in their own statements.

What "Quant AI" means in this statement

"Quant AI" refers to the AI inference and agent services provided as part of the Quant platform. This includes:

• Chat inference (REST, HTTP streaming, and WebSocket interfaces)
• Agents, tools, skills, workflows, orchestrations, and triggers configured by customers
• Text and image generation, text embeddings
• AI-powered search and retrieval

This statement applies only to these AI services. It does not cover other parts of the Quant platform (CDN, edge compute, hosting) that do not process prompts or generate AI output.

Foundation models we use

Quant does not train its own foundation models. All generative AI in Quant is delivered through Amazon Bedrock, using foundation models from third-party providers. The families currently available to customers are:

• Anthropic Claude — Opus, Sonnet, and Haiku lines (multiple versions)
• Amazon Nova — Pro, Lite, Micro, and Canvas (image)
• Amazon Titan — text and image embeddings

The specific models available at any point in time, and their release and deprecation status, are maintained in our platform's models catalogue and surfaced to customers via API and portal. Customer organisations can restrict which models are approved for their use through model allowlists or blocklists.

Where data is processed

Quant's AI platform is hosted in Australian AWS regions:

• Melbourne (ap-southeast-4) — audit log storage, platform services
• Sydney (ap-southeast-2) — Amazon Bedrock inference, AI Lambda services

All supported foundation models are invoked using one of two routing paths, both of which keep data inside Australia:

• Direct Sydney serverless invocation — request and response stay in ap-southeast-2.
• Australian inference profile (au.) — inference is pooled across ap-southeast-2 (Sydney) and ap-southeast-4 (Melbourne) for capacity. All traffic remains in Australian AWS regions.

Quant does not use APAC or global inference profiles for any supported model. Models that have no Australian routing path are not made available to customers.

How we handle your data

Prompts, responses, and training

Quant does not use customer prompts, completions, tool calls, or files to train any model.

Amazon Bedrock's published position — which Quant relies on and which is contractually binding on AWS — is that customer inputs and outputs are not used to train AWS models and are not shared with the third-party model providers (including Anthropic). Foundation model providers do not receive customer prompts or outputs when those models are invoked through Bedrock. AWS documents this at docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html.

Tenancy isolation

Every AI request is scoped to a customer organisation. Session state, audit records, usage counters, and governance configuration are partitioned by organisation identifier in DynamoDB and S3. Customer organisations cannot read or influence other organisations' data through the AI APIs.

Encryption

Data is encrypted in transit (TLS) and at rest. The AI audit log bucket uses AWS KMS server-side encryption; other AI service storage uses AES-256 server-side encryption by default.

Safety controls

Quant ships three pre-configured guardrail presets aligned to the Australian Government Protective Security Policy Framework (PSPF):

• OFFICIAL — baseline content safety (hate, insults, sexual, violence filters at high strength); AWS-provided PII detection (credit card, AWS keys); custom regex detection for Australian identifiers including Tax File Number, Australian Business Number, and Medicare number; contextual grounding checks.
• OFFICIAL:Sensitive — stricter content filtering with misconduct category enabled; broader PII detection including names, email, phone, IP address, and URL anonymisation; word and topic policies covering classified terminology; higher grounding thresholds.
• PROTECTED — strictest filtering; extended PII detection including vehicle and licence identifiers; denied topics including military operations, intelligence sources, critical infrastructure vulnerabilities, and cabinet documents; denied terms including AUSTEO and AGAO; high grounding thresholds.

Customer organisations can designate a mandatory guardrail preset at the organisation level. When set, this preset is applied to every inference request made on behalf of that organisation, regardless of the surface the request came from (portal, API, agent, workflow). Individual agents may add stricter overlays but cannot weaken the mandatory preset.

Guardrail behaviour, including which category triggered a block or redaction, is recorded in the audit log for every request.

Custom filter policies

Alongside the PSPF guardrail presets, Quant supports a second layer of safety control: rule-based filter policies that apply on input, output, or both directions. Each rule specifies a match (literal word list or regular expression) and an action — BLOCK (reject the request or response) or REDACT (mask the match with placeholder text before the model sees it, or before the response reaches the caller).

Two categories of filter policy are available:

• Built-in policies shipped with the platform — for example, Australian driver licences for all states and territories, Australian passport numbers, and common secrets and tokens (API keys, bearer tokens, SSH private keys, GitHub, Slack, and Stripe credentials). Each built-in can be enabled or disabled per organisation.
• Custom policies authored by customer organisations with their own rules. Custom policies can be marked mandatory at the organisation level — in which case no agent, tool, or individual request can bypass them — or attached selectively to individual agents.

Filter policies are additive to the guardrail preset. A request must pass all applicable filter policies and the applicable guardrail preset. Policy hits (which rule matched and what action was taken) are recorded in the audit log for every request.

Human oversight

Quant AI services produce outputs that may contain errors, omissions, or biases. Customers are responsible for human review of AI outputs before using them for any decision affecting individuals, communities, or the public. Quant does not recommend that AI outputs be acted upon without human review in any context where the policy's in-scope criteria apply (for example, administrative decisions or public-facing interactions).

Audit and retention

Every AI inference request produces an immutable audit record that includes: user and token identity, organisation, session identifier, request identifier, timestamp, model, interface, token usage, tool calls, and cryptographic hashes of the prompt and response. Optional full prompt and response content storage is available on a per-organisation basis.

Audit records are written to an S3 bucket with Object Lock in compliance mode and a default retention of seven years. This aligns with Australian Signals Directorate ISM event log retention guidance. Records cannot be deleted or modified within the retention period — not by Quant staff, not by customers. Public access is blocked. KMS encryption applies.

Customer organisations can request export of their own audit records at any time. Audit records are scoped by organisation; no organisation can access another's audit records.

Governance controls available to customers

Each customer organisation controls, at a minimum:

• Whether AI services are enabled at all (organisation-wide master switch)
• Which foundation models may be used (allowlist or blocklist)
• Which mandatory guardrail preset applies to all AI traffic
• Spend limits — organisation-wide monthly and daily caps, and per-user monthly and daily caps
• Role-based access to AI configuration (agents, tools, skills, workflows, filter policies, governance)
• Scoped API tokens with per-organisation and per-project boundaries

Known limitations

• Model output quality. Foundation models can produce inaccurate, incomplete, or biased output. Quant's contextual grounding thresholds reduce but do not eliminate hallucination.
• PII detection is not exhaustive. Quant's Australian-specific regex patterns (TFN, ABN, Medicare) catch correctly formatted identifiers but cannot detect all references to an individual. Guardrails reduce risk; they do not replace a privacy impact assessment.
• IRAP status. Quant has completed IRAP assessment. Contact us for the current assessment summary.

Raising concerns

Concerns about Quant AI services — including suspected safety issues, unintended behaviour, or potential harms — can be raised at any time by emailing security@quantcdn.io.

If your use of Quant AI is public-facing (for example, a citizen chatbot), your agency is responsible for providing a pathway for members of the public to raise concerns directly with you. This pathway is a mandatory requirement of the DTA AI policy. Quant can support your triage of such reports by providing audit records on request.

Review and maintenance of this statement

This statement is reviewed annually, or sooner if there is a material change to Quant's AI services — for example, a change in hosting region, a new model provider, or a change in data handling practices. Material changes are communicated to customer organisations through normal service-update channels.