Poland and OpenAI formed a safety partnership. Publish the research queue

THE SIGNAL IN ONE SENTENCE

A partnership announcement is a door opening. It is not the research walking through it. On October 23, Poland's NASK National Research Institute and OpenAI announced an agreement to explore collaboration on AI safety, security and technical research. NASK's AI Safety Research Center, which serves as the Polish Artificial Intelligence Safety Institute, will lead the work on the Polish side. The two official announcements name a broad field. They point to evaluation of increasingly capable AI systems, possible vulnerabilities, stronger safeguards, synthetic content, malicious uses and risks that change across languages. They also connect the partnership to international work on technical standards, incident reporting and safer advanced models. That is meaningful territory. It is not yet a research program a member of the public can inspect. Neither announcement provides a budget, timetable, list of named projects, model-access rules, test datasets, publication schedule, data-sharing terms or promised deliverables. The agreement creates a route for collaboration. It does not prove that a particular evaluation has begun or that a particular safeguard works. The plain signal is this: publish the research queue. A public research queue is not a glossy roadmap full of arrows pointing toward trust. It is a dated list of the questions the partnership intends to answer, who owns each question, what evidence will count, what can be published and what remains blocked. Start with the question. "Study multilingual risk" is too wide to test. A useful queue item might ask whether a model detects a defined form of impersonation equally well in Polish and English, whether it produces different rates of harmful assistance after the same intent is expressed through slang or spelling variation, or whether a synthetic-content detector loses accuracy on locally relevant speech and images. Each item should name the model snapshot, language, task, threat, affected users and decision the result will inform. If the question cannot be written clearly, the partnership is not ready to claim an answer. Then name the method. Publish the evaluation protocol before the final score whenever doing so will not create a security problem. State who built the test set, who reviewed it, how examples were sampled, what the baseline is, what counts as success, how uncertainty is measured and which failures receive manual review. This matters because a benchmark can become a little stage. The model learns the shape of the test, the test leaves out the difficult local cases, and everybody applauds the lighting. Polish users do not encounter AI only in laboratory English. They encounter it in schools, public services, media, cybersecurity operations and ordinary conversations. Tests should include the language people actually use, including formal administrative language, informal speech, mixed-language prompts and attempts to evade safeguards through spelling or context. Local expertise is the point of the partnership. OpenAI says national partners help prevent global safety standards from becoming detached from the places where AI is used. NASK says it brings experience protecting public services and Poland's digital information environment. The research queue should show how that expertise changes the test, not simply place a Polish institution's name beneath a global template. For every multilingual evaluation, publish the language coverage and the gaps. State whether examples were written by native speakers, translated from another language or generated by a model. Record regional and demographic limits. Give reviewers a way to flag examples that are technically fluent but socially absurd. Translation is useful. It is not the same thing as local evidence. The queue also needs evaluation access. NASK cannot independently challenge a frontier system with a brochure and a carefully selected demo. It needs permission and technical means to operate an exact model version under defined conditions. The public record should say whether NASK designed the test, ran it, observed it or merely received a result from OpenAI. Those are different levels of independence. For each project, disclose the tested model snapshot, tool access, system instructions, safety settings, rate limits and any developer assistance that could change the result. If full details must remain confidential, publish the category of the restriction and who verified the hidden evidence. A company can be a valuable research partner and still have an interest in how its systems are described. NASK can bring public-interest expertise and still face limits on access, staff, funding or disclosure. Naming those conditions is not an insult to the partnership. It is how readers understand the evidence. Security work requires a second lane. Some findings should not be published immediately. A new vulnerability, jailbreak or reliable method for malicious use can cause harm before a repair exists. The research queue should therefore include a responsible-disclosure state: reported, reproduced, repair in progress, fixed, independently verified and public summary released. Sensitive exploit detail can stay restricted while dates, affected control categories and repair status become public. A confidential drawer is reasonable. A black hole is not. The partnership already has one practical precedent. NASK and OpenAI say CERT Polska received access to cyber-capable models through the Daybreak program in July. The team used them while finding six vulnerabilities in MikroTik RouterOS. Some flaws could be combined to take control of affected devices without authentication. The vendor issued fixes, and CERT Polska confirmed that the fixes blocked the attacks it observed. That example contains the bones of a useful receipt: a named defender, a defined target, discovered vulnerabilities, vendor remediation and confirmation after repair. The new queue should preserve that shape while adding the missing operational detail that can be shared safely. How much human work did the model save or create? Which suggestions were wrong? What access did the system receive? Did the work begin from a known lead or from open exploration? Which tests confirmed the repair? What remained outside scope? Negative results belong in the queue too. If a proposed detector fails on Polish synthetic audio, publish the failure. If a jailbreak method does not transfer across model versions, publish that. If evaluators cannot reach a conclusion because access changed or the dataset is too small, mark the item inconclusive rather than quietly removing it. A research partnership becomes more credible when the disappointing work remains visible. The queue should separate four statuses: proposed, active, under responsible disclosure and complete. Each item should carry a date, lead institution, research question, model or system under test, method summary, expected artifact, publication level and next checkpoint. Completed items should link to evidence. That might be a paper, protocol, dataset card, evaluation report, vulnerability advisory, safeguard change, incident template or standards proposal. A completed item with no public artifact should explain why. The queue should also record changes. Frontier systems move quickly. A model version can disappear before an evaluation report is finished. Safeguards can change halfway through a test. A dataset can become contaminated by public discussion. The record should preserve which version was tested and whether the result still applies to the version people can use. Do not overwrite the old line with the new answer. Keep the history. Public services deserve especially careful boundaries. NASK's role in Poland's digital ecosystem makes it a natural partner for evaluating systems that may affect government operations or public information. Real public-service data should not become convenient test material without a lawful purpose, access controls, minimization and a deletion plan. Start in isolated environments. Use synthetic or de-identified records where they are appropriate, but state what those substitutes fail to represent. Require human authority for consequential decisions. Test failure recovery before any live pilot. Publish the difference between an advisory tool and an automated decision maker. The research queue is not a demand to publish every secret. It is a demand to publish the shape of the work. The public should be able to see which questions are being asked, which are waiting, which produced evidence, which hit a security hold and which were abandoned. Researchers outside the partnership should be able to identify gaps, propose replications and understand whether a finding applies to Polish users, another language or only one protected laboratory setup. OpenAI frames the agreement as part of a wider international effort to align capability evaluation, risk assessment, safeguard testing and incident reporting. NASK describes the agreement as unique within the European Union and says the work will combine Polish research expertise with OpenAI's technical capabilities. Those claims raise the standard for the receipt. If the partnership helps shape common approaches, its methods should be legible enough for other public institutes to compare. If Poland brings local expertise, the queue should show which risks and languages entered the agenda because Polish researchers were in the room. If the work strengthens safeguards, readers should eventually see which control changed and what test supports the change. An agreement can create access, trust and a place to work together. Good. Now turn that access into an inspectable sequence. Question. Method. Access. Test. Finding. Repair. Publication. Put every project in the queue. Then let the evidence move it forward.