Private LLM chat for ISO 42001

The AI policy under control A.2.2 is a written document that sets out how the organization develops or uses AI systems, and no tool writes it for you. The policy is an organizational document approved by leadership, which clause 5.2 of ISO/IEC 42001 requires to exist. Your Open WebUI or LibreChat deployment supports the policy but cannot author it. Draft the policy to name the approved models, permitted data types, and who may create accounts, then reference the self-hosted configuration as the implementation. Your statement of applicability should list A.2.2 and justify its inclusion. Confirm the exact wording and approval workflow with your certification body or internal audit team before drafting.

Control A.9.2 expects you to define and document the processes your organization follows for responsible use of AI systems. These processes are written by your team, covering onboarding, acceptable use, data handling for uploads, incident reporting and access reviews. The platform produces supporting evidence: group membership exports, role assignments and the logs described in this section. Tooling cannot define the process itself, so keep the written procedure as the primary artifact and attach configuration screenshots or exports that show it operating. Ask your implementation partner to map each configured control to the procedure step it enforces.

Your leadership and governance function writes the objectives for responsible use under A.9.3, because they reflect organizational goals and risk appetite. Examples include restricting sensitive data categories from prompts, achieving a defined review cadence for user access and documenting model changes. The chat platform can support measurement, for example through usage reports or log queries, but it cannot set the target. Record each objective with an owner, a measure and a review date, then link the measure to a report your team can export. Confirm with your governance lead which objectives your board or AI committee has already approved.

Control A.9.4 asks you to ensure the AI system is used according to its intended uses and its accompanying documentation. The intended use statement should name the purpose of the assistant, the user population, the models offered, the data classes that may be entered and the prohibited uses. Pair it with accompanying documentation such as a user guide and admin runbook for the self-hosted deployment. Describe the model endpoints as internal, which helps reviewers confirm that prompts stay in your infrastructure. Have legal and the data protection officer review the statement before publishing it to staff.

Role-based access and group configurations show which staff can reach which models and features, which supports the intended use and responsible use controls. Open WebUI documents SSO through OIDC and LDAP, SCIM 2.0 provisioning, groups and per-resource permissions, so you can export the group structure and permission assignments as evidence. Keep an access review record showing who approved each group and when membership was last checked. Confirm the exact export options for your Open WebUI or LibreChat version, since the admin interface and API differ between releases. Your partner should document how provisioning from your identity provider maps to these groups.

Usage logs and retention settings show what was done with the assistant and how long the records are kept. For high-risk AI systems, Article 12(1) of the EU AI Act requires technical capability for automatic event logging over the system lifetime, and Article 19(1) requires providers to keep logs for at least six months unless other law provides otherwise. Whether your assistant is high-risk depends on its use, so confirm that classification with counsel before relying on those figures. Configure retention in the chat platform and in the gateway or proxy layer, and document where each log lives and who can read it. Verify these settings in your own environment before the first audit.

The statement of applicability lists the Annex A controls your organization has chosen to implement or exclude, with a justification for each decision, as clause 6.1.3 of ISO/IEC 42001 requires. For a staff chat assistant, expect A.2.2, A.2.3, A.2.4, A.9.2, A.9.3 and A.9.4 to appear, along with any impact assessment or data controls your scope triggers. The platform does not decide inclusion; your risk assessment and governance team does. Document why any control is excluded, for example if no third parties process chat data. Ask your certification body how they expect the justifications to be written before finalizing the document.

No single platform satisfies ISO/IEC 42001 because the standard is a management system, and most evidence is organizational. A self-hosted deployment supports the audit by keeping prompts, files and logs in infrastructure you control and by producing configuration, access and log records. Policy, processes, objectives and intended use remain your documents. ISO does not certify organizations; accredited certification bodies do, and accreditation of those bodies is voluntary. DeployOpen prepares systems, controls and evidence for compliance assessments but does not issue audit reports or certifications. Confirm the scope of your assessment with the certification body you select.

No. A chat tool is one component of an AI management system, and ISO/IEC 42001 is a management system standard that asks how the organization governs AI across its activities. Self-hosting helps with evidence, because prompts, files and chat history stay in infrastructure you control and can be described in your documentation. Conformance still depends on a documented AI policy, defined processes for responsible use, stated objectives, a record of intended use, risk handling and internal review. Certification is issued by an external certification body, not by a tool vendor or by DeployOpen.

The AI policy control (A.2.2) asks for a documented policy covering the development or use of AI systems, and clause 5.2 requires that the policy exists. For a staff assistant, the policy should state which models and data classes are permitted, who may use the tool, and what acceptable use looks like. The statement of applicability, required by clause 6.1.3, lists each Annex A control you include or exclude and justifies that decision. Expect the chat assistant to bring in controls for responsible use (A.9.2), objectives for responsible use (A.9.3) and intended use (A.9.4), so these need written process owners and evidence.

Four factors drive most of the effort. The first is the number of Annex A controls in scope, since the standard has 38 controls across nine objective areas and you are not required to implement all of them. The second is whether you already run an ISO/IEC 27001 management system, because the harmonized structure lets many clauses and document types be reused. The third is the size of the user base and the logging design, since the EU AI Act's log retention and automatic recording expectations apply only where high-risk systems are involved, and your own retention rules will set the bar for chat history. The fourth is how many business units, models and integrations the assistant touches. Ask for a written scope that names each factor before accepting a quote.

Often yes, provided the team has someone who understands the standard's clauses and Annex A, and the time to write and maintain the documents. Internal teams usually handle the technical configuration well, including SSO, groups, model endpoints and log settings. Where teams struggle is the management system itself: the policy, the statement of applicability, the risk and impact assessments, the internal audit cycle and the management review. Outside help is most useful for a gap assessment, for drafting evidence that auditors will test, and for hardening and documenting the self-hosted platform. Use the ISO 42001 standard page to confirm scope before deciding what to build internally.

Three things matter most. The first is leadership sponsorship, because clause 5 expects top management to own the AI policy and to commit resources. The second is named process owners for use, data handling, access, incident response and user training, who can explain how the assistant is really used. The third is access to the environment: the Open WebUI or LibreChat configuration, identity provider settings, model server details, logging and storage, and any existing ISO 27001 documentation. Also expect the partner to ask for a list of approved use cases and the data classes staff may paste. Gathering these before the scope is written shortens the discovery phase.

Logging determines what you can show an auditor. Decide early which events are recorded, such as sign-ins, role changes, model selection, administrative actions and, where your policy allows, prompt and response content. Each choice affects storage, privacy obligations and the access controls on the log store. Confirm retention periods with your legal and records teams, and check whether any high-risk classification under the EU AI Act applies to your use case, since Article 12 and Article 19 set specific log expectations in that case. Do not assume the chat interface's default settings meet your policy until you have tested them.

Certification applies to the organization's AI management system, not to a product, and only an accredited certification body can issue it. ISO/IEC 42006:2025 sets additional requirements for bodies that certify AI management systems. Ask a partner to explain how they prepare the management system for an external assessment, which evidence they produce, how they test controls before an audit, and how they handle documentation updates when the chat platform releases new versions. Ask them to put scope, deliverables, exclusions and the quote process in writing, since DeployOpen works from fixed, written scope and does not publish a price list.