OpenAI and NASK: AI safety collaboration and lessons for architects

What was actually announced?

Facts established by the parties' announcements

On 23 October 2026, OpenAI and Poland's NASK National Research Institute announced an agreement to explore cooperation on artificial intelligence safety, cybersecurity and technical research. NASK's AI Safety Research Center, which serves as the Polish AI Safety Institute (AISI), is involved in the planned collaboration.

The organizations intend to study the capabilities and risks of increasingly advanced AI systems, identify potential vulnerabilities and strengthen safeguards. NASK also highlighted research into synthetic content, malicious uses of AI and threats that vary across languages.

The public statements do not provide a complete timetable, budget, detailed testing methodology or a defined set of final deliverables.

ArchitectMentor interpretation

Announcing a research partnership is not the same as delivering a joint testing platform, an independently validated model-evaluation process or a new security standard. Its significance should ultimately be judged by the evidence, methods and results that become available for scrutiny.

From model security to system security

Traditional cybersecurity already requires us to consider identity, permissions, interfaces, data, infrastructure and incident response. These concerns do not disappear when an organization adopts AI. New risks arise from prompt injection, misuse of tools, unintended disclosure of information through model context, and actions based on unreliable or manipulated responses.

The distinction becomes especially important in agent-based architectures. An AI model that merely suggests an answer presents a different risk profile from an agent authorized to read internal documents, invoke APIs or change business records.

Architectural assessment

Security evaluation should therefore cover the complete system: the model, system instructions, retrieval mechanisms, connected tools, service identities, permissions, action-approval controls and audit trail. It should not stop at a benchmark score for the underlying language model.

The organization designing and operating the application remains accountable for its security boundaries, even when the model is provided by a third party.

What CERT Polska's RouterOS research shows

A documented example

A relevant precedent is CERT Polska's research into six vulnerabilities in MikroTik RouterOS, described in September 2026. The research team used AI models within a controlled environment to support vulnerability investigation.

CERT Polska's technical account describes an isolated laboratory in which an agent helped automate experiments, create and restore test environments, compare software versions, analyze protocols and develop verification scripts. Researchers selected the areas to investigate and supervised the work.

Hypotheses were tested against real RouterOS systems, including negative controls, repeated experiments on clean systems and human assessment of their impact. The published account does not establish that an AI system independently discovered and validated every vulnerability without expert oversight.

ArchitectMentor takeaway

AI can expand the number of hypotheses a research team can explore and reduce the effort involved in experimentation. Credibility, however, comes from a reproducible verification process. For architects, the safeguards and evidence surrounding an AI system may matter more than the choice of model itself.

What should enterprise architects expect from AI assurance?

AI assurance is a useful term for the practices and evidence needed to establish that an AI system meets defined quality, security and compliance requirements in a particular context of use.

ArchitectMentor proposes five elements for practical assurance.

1. A defined use case. Establish what the system is meant to do, what information it processes, who uses it and what could happen if it fails.

2. Threat modelling. Evaluate attacks on the model together with excessive agent permissions, integration weaknesses, manipulated knowledge sources and loss of control over business processes.

3. Repeatable evaluation. Specify acceptance criteria, representative datasets, model versions and a method for comparing results after each material change.

4. Verifiable evidence. Make it possible to reconstruct relevant inputs, tool calls, decisions and outcomes while respecting data-protection and retention requirements.

5. Lifecycle oversight. Reassess risks whenever models, instructions, retrieval sources, tools or access privileges change. Assurance cannot end when the system goes live.

These five elements are ArchitectMentor's proposed framework. They are not announced deliverables of the OpenAI–NASK agreement.

Who evaluates the AI provider?

Collaboration between a model developer and a public research institute can bring together advanced technical capabilities, independent expertise and knowledge of country-specific threats. It also raises legitimate questions about the independence and transparency of evaluations.

Will researchers be able to test scenarios beyond those suggested by the provider? Can unfavourable results be disclosed? Will the methods allow different models to be compared? Who is responsible for acting when a significant weakness is identified?

The announcements do not yet provide sufficient detail to answer those questions.

ArchitectMentor position

AI governance maturity should be measured by the quality of verifiable evidence, not by the number of public statements about responsible AI. Valuable future outcomes might include comparable evaluation methods, well-defined threat scenarios, techniques for testing agents and procedures for responding to unsafe behaviour. These are potential directions, not products already promised or delivered by the partnership.

What does this mean for enterprise architecture?

The practical implications extend beyond the announcement. Before introducing AI into a business process, an architect should be able to answer three questions.

What can the system do? Identify its actual permissions, data access, exposed interfaces and authority to perform operations.

How do we know it works safely? Require measurable evaluation scenarios and evidence that those tests were performed.

What happens when it crosses an acceptable boundary? Design ways to suspend actions, revoke access, handle incidents and reconstruct what happened.

Research collaboration between OpenAI and NASK may eventually help organizations strengthen these practices. At this stage, however, the agreement should not be mistaken for a certification mechanism, a guarantee of security for OpenAI products or a change to the responsibilities of organizations deploying AI.

Conclusion: trust requires evidence

The partnership is a significant signal of cooperation between an advanced model developer and a public institution focused on security. The architectural challenge is to translate research findings into design requirements, technical controls and decisions throughout the system lifecycle.

AI safety is not a permanent property that can simply be assigned to a model. It is a claim about a system that must be supported by evidence and reassessed over time.