SOURCE / EVENT DATE23 Oct 2026

OpenAI and Poland’s NASK National Research Institute have agreed to explore cooperation on AI safety, security and technical research. Announced on October 23, the partnership links a frontier-model developer with a public institute working on the risks that increasingly capable systems can create.

The useful question is what the researchers will be able to test. A partnership can create access to people and systems that outsiders would otherwise struggle to study. Its value becomes easier to judge when that access leads to a defined experiment, an explainable finding and a repair that can be checked.

This explainer separates the announced scope from the work still needed. It also places the agreement beside NASK’s earlier cyber-defense collaboration and Europe’s discussion of external AI evaluators. None of those strands, by itself, amounts to certification that an AI system is safe.

In this article
  1. What the agreement says — and what it leaves open
  2. A public chatbot test and a controlled evaluation reveal different things
  3. The earlier cyber-defense relationship is useful context
  4. Europe’s regulatory timetable is a separate layer
  5. Independence needs operating rules
  6. What would count as measurable progress?

What the agreement says — and what it leaves open

OpenAI identifies NASK’s AI Safety Research Center as Poland’s Artificial Intelligence Safety Institute. The announced research interests include evaluating increasingly capable systems, finding vulnerabilities and improving safeguards. NASK also highlights synthetic content, malicious use and multilingual challenges.

The public announcement leaves important operating details unspecified. It supplies no budget, timetable, benchmark list or promise to publish results. That limits what a reader can conclude today. There is an agreement to explore collaboration; there is not yet a publicly described testing program with measurable completion criteria.

An early-stage agreement can still be useful. The next step is to turn broad interests into a question that an experiment can answer. Which model version is being assessed? Which capability or safeguard is under examination? What result would count as a failure? Those are proposed questions for the future work, rather than terms disclosed in this pact.

Sources: OpenAI — NASK AI safety and security agreement, October 23, 2026 ↗

A public chatbot test and a controlled evaluation reveal different things

Imagine a researcher testing a hypothetical assistant that handles public-service questions. Asking it questions through a normal interface can reveal visible mistakes. A deeper evaluation might also examine the tools it can call, the permissions attached to those tools and how the system responds when a task goes wrong. These are different views of the same application.

For this partnership, useful reporting would explain the access granted to evaluators. Readers should be able to distinguish ordinary user access from special testing arrangements. They should also know whether findings concern the model itself, the surrounding application, or the infrastructure running it.

That distinction keeps a finding in proportion. An error in one application does not establish the behavior of every deployment. Equally, a successful test of one configuration leaves other configurations open. This is a proposed way to read future evidence, not a description of tests NASK has already completed under the agreement.

A close-up of colorful programming code on a laptop screen in a dark room.
Meaningful evaluation needs a defined system and test conditions. Illustrative stock photograph; this is not code or an evaluation result from NASK.Vishnu Kalanad / Unsplash ↗

The earlier cyber-defense relationship is useful context

NASK’s July 2 announcement described access to OpenAI’s specialized cyber model for CERT Polska, the incident-response team operating within the institute. It discussed using the tool to help analysts find vulnerabilities, analyze threats and support remediation.

That earlier statement also preserved a human responsibility: specialists verify the model’s work. Access to a capable tool does not remove the need to check a suspected vulnerability or validate a proposed fix. The July activity therefore helps explain the existing relationship without proving what the October research agreement will deliver.

The distinction is practical. Helping defenders inspect software and evaluating the risks of an AI system can overlap, but they ask different questions. A convincing report should identify which job was performed and which evidence supports its conclusion.

Sources: NASK — Earlier cyber-model access for CERT Polska, July 2, 2026 ↗

Europe’s regulatory timetable is a separate layer

The European Commission’s general-purpose AI guidelines distinguish several dates. Obligations for providers of newly placed GPAI models began applying on August 2, 2025. The Commission’s enforcement powers began applying on August 2, 2026. Models placed on the market before August 2, 2025 have a later compliance date of August 2, 2027.

Those dates provide context for October 2026 discussions about evaluation. They do not turn an agreement between a company and a research institute into regulatory approval. The Commission also describes its guidelines as an interpretation of the law, rather than a legally binding instrument in their own right.

For readers, the sound distinction is between a voluntary research relationship, an evaluator’s technical findings and a regulator’s legal powers. Evidence from one setting may become relevant in another. The announcement does not establish that such a regulatory role has been assigned to this partnership.

Sources: European Commission — GPAI provider guidelines and application dates ↗

Independence needs operating rules

The AI Office’s June call for an external-evaluator workshop focused explicitly on qualifications and independence. It asked how evaluations commissioned by general-purpose model providers could remain credible and reliable. That is relevant background to the wider evaluation debate; it is not an endorsement or assessment of the NASK agreement.

A proposed checklist for future reporting starts with simple questions. Who chooses the tests? Can researchers report an unfavorable result? How are conflicts of interest handled? If a finding contains sensitive security details, is there a process for disclosure and later public explanation?

Cooperation and independence need not be mutually exclusive. They do need terms that readers can understand. A press release naming respected institutions cannot answer those operational questions on its own.

Sources: European Commission — External-evaluator independence and qualifications workshop ↗

What would count as measurable progress?

Useful next artifacts would include a defined research scope, dated methods, the model and environment tested, and a clear explanation of the result. A report of a repaired vulnerability would be stronger if it also explained the retest and its limits. Sensitive technical details may require controlled disclosure, while high-level methods and limitations can still help the public interpret the work.

The standard should remain consistent over time. Separate an intended project from a completed experiment, and a completed experiment from a broad assurance about safety. That gives readers a way to recognize progress without asking one partnership to prove more than its evidence supports.

OpenAINASKAI safetyPolandEU AI Actmodel evaluation