NIST AI RMF
Summary
The NIST AI Risk Management Framework (AI RMF 1.0) is a voluntary United States framework that organizes AI risk work into four functions: Govern, Map, Measure, Manage. It is not a certification and no body audits or issues findings against it; organizations state their own alignment. This page is Infer's statement, and it forms part of Infer's compliance program.
Infer operates deployment infrastructure for open-weight models. We do not train models, fine-tune them, or modify their weights. That places our risk surface at the serving layer: availability, isolation, confidentiality of request content, integrity of what is served, and honest description of it. Content-level AI risk (what a model outputs, whether an output is fit for a decision, and what oversight sits around it) belongs to the developer of the model's weights and to the customer building the application. This page states how Infer addresses the four functions inside its own scope, and where the boundary falls.
The four functions, within our scope
Each function below is stated against what Infer actually operates. Where a function is largely outside a serving operator's scope, we say so rather than claiming coverage we do not have.
Govern
Accountability is named, not diffuse. Infer designates a Security Officer in writing as the single accountable owner for security, privacy, and risk decisions. A written risk analysis and a set of security policies and procedures (access management, workforce security, incident response, contingency planning, and sanctions) are documented and are undergoing counsel review ahead of launch. The compliance program is published, so the governance posture is stated in public rather than held internally, and each page carries a status line that is updated as milestones complete.
Map
Mapping context means being exact about what is being served and to whom.
- Provenance. Infer serves a published open-weight model without modification. We do not train, fine-tune, distil, or otherwise alter weights, so the model's own documentation and its developer's evaluations remain the authoritative description of its behaviour.
- Disclosure of the serving configuration. For each model we serve, we disclose exactly what is served: the model and its version, the quantization format, the context length, and the operating limits. A quantized deployment is a changed artefact in practice, so we name the format rather than implying stock weights.
- Deployment context. Requests reach Infer through a single authorized upstream caller, our routing partner. End users never connect to Infer directly, and Infer holds no relationship with, and no data about, the end user behind a request.
Measure
Measurement is only useful if its provenance is legible. The site follows one convention throughout: a figure is either a design target or a measured result, and it is labelled as such. Infer is pre-launch and serves no production traffic yet, so performance and behaviour figures published today are design commitments; each is replaced by a measured figure, with the conditions of measurement stated, as the service enters operation. Measurement of the serving layer covers latency, throughput, admission behaviour under load, and availability. It does not extend to benchmarks of the model's task quality: those belong to the model's developer and to the customer's own evaluation of fitness for their use case.
Manage
Risk is managed with mechanisms that hold under load rather than with intentions.
| Risk | Mechanism in operation |
|---|---|
| Overload | Admission control sheds excess load with 429 at the edge. There are no hidden queues, so a saturated system degrades by refusing work rather than by silently inflating latency. |
| Replica loss | Gateway failover absorbs the loss of a compute replica; in-flight volatile state on that replica is destroyed with it and is never reconstructed. |
| Content exposure | Zero data retention bounds the blast radius of any incident: prompts and completions live only in volatile memory for the life of a request and its transient session cache, are never written to durable storage, never logged, and never used for training. Logs are metadata-only by construction. |
| Personnel access | No internal tool, console, or export path surfaces customer content to personnel. Debugging is performed with synthetic traffic. |
| Transport | TLS terminates at the external edge; traffic between the gateway and compute runs over an encrypted overlay network. |
| Incidents | A written incident response procedure defines detection, assessment, and notification. A tabletop exercise of that procedure is part of pre-launch operational readiness. |
Scope and shared responsibility
The division of labour is set out in the shared responsibility section of the security overview, and the AI RMF functions divide along the same line.
| Infer owns | The customer owns |
|---|---|
| Serving the published model faithfully and describing the deployment accurately. | Deciding that the model is fit for the task, and evaluating it against their own acceptance criteria. |
| Availability, admission behaviour, isolation, and confidentiality of request content in transit and in memory. | What is placed in a prompt, including whether sending particular data to a hosted model is permitted by their own policy and obligations. |
| Metadata-only logging, zero retention, and incident response for the serving platform. | How outputs are used, reviewed, and disclosed, including human oversight, content filtering, and any notice to affected people. |
| Publishing status, figures, and limits honestly, and updating them as they change. | Application-level risk management, including recording their own AI RMF or equivalent posture for the system they build. |
Infer does not observe how an application uses a completion, and by design cannot: we hold no content and no end-user identity. Human oversight of AI-assisted decisions is therefore a control the customer implements, and one we assume exists wherever outputs carry consequence.
Review
This statement is reviewed on the same cadence as the rest of the compliance program, and is revised whenever the service changes in a way that alters it: a new model listed, a change to the served configuration or quantization, a material change to admission or failover behaviour, or an incident that produces a lesson worth recording. The status line at the top of this page and its Last updated date carry the result of each review.
Questions about this statement, or a request for the supporting detail behind any line of it:
contact@infer.industries