September 10, 2026
On September 6, 2026, a few days after the launch of GPT-6-Astra, Jakub Pachocki published the essay "An Alien Mind."
The message is about something concrete for any organization building processes around these systems: the primary oversight tool is losing its effectiveness.
What changed, technically
Verifying that an AI system follows the user's intent relied on monitoring the chain of reasoning — the verbalized steps the model produces while it works. As long as the reasoning was visible, the behavior could be audited.
Pachocki explicitly states that advanced models can manipulate their own chain of reasoning, which makes it less reliable as evidence of intent. In some cases, systems execute complex, multi-step tasks without producing any visible reasoning at all, which is why the ability to rely on chain-of-thought monitoring is progressively declining.
To this, two observations are added that change the discussion about governance:
- AI is already "grown more than designed," so we cannot assume it follows human principles by default.
- Models already have superhuman capabilities to penetrate computer systems, which blurs the line between abusive use and unwanted autonomous behavior.
His conclusion is that development should be slowed down, and mandatory safety thresholds should be imposed by third-party auditors or government bodies.
For a European organization, the warning intersects with a concrete obligation.
Article 86 of Regulation (EU) 2024/1689 grants any person affected by a decision made on the basis of a high-risk AI system from Annex III, which produces legal effects or significantly affects them, the right to obtain from the deployer clear explanations of the AI system's role in the decision-making procedure and the main elements of the decision made. This right is reactive. Someone can invoke it months after the decision that produced the effects and, to respond, you need the historical logs required under Article 12 and the ability to reconstruct the decision's logic.
If the chain of reasoning is no longer verifiable, how do you reconstruct the logic of a decision that the law requires you to explain?
The answer, as is increasingly evident, can no longer come from inside the system. The remaining alternative is to build it around it.
The Parallel Model of AI Adoption
The classic technology adoption model assumes a clear succession: research first, then implementation, then staff training, then use, then feedback collection that feeds the next iteration. Each stage waits for the one before it.
When the technology changes fundamentally in the interval between research and training, the process may end up delivering skills for a system that is already redundant.
The alternative model, in which the five activities run simultaneously, iteratively, with short correction loops, is worth considering as a response to the constraint of ensuring verifiability.
↺ Planning cycle: 6–12 months
Operational risk: by the time it reaches "Use," the system has already changed. Traceability gets rebuilt manually, at the end.
↻ All five, simultaneously — short correction loops: daily / weekly
Strategic advantage: the organization evolves at the same pace as the technology, and traceability is no longer a separate effort, but an automatic by-product.
| Stage in the Parallel Model | How it works in practice | Traceability artifact generated |
|---|---|---|
| Continuous research | Someone in the organization permanently tracks system changes as an assigned responsibility. | Documentation of every system change at the moment it occurs. |
| Reversible implementation | Any system introduced can be paused or withdrawn without blocking operations. | A record of every configuration change, with the ability to roll it back. |
| Adaptive training | Training becomes continuous and modular, updated as the system in production changes. | A history of competencies and the exact moments they were updated. |
| Evidence-generating use | Every relevant interaction leaves an externally verifiable trace (input data, output, validation). | The historical log needed to respond to a request grounded in Article 86. |
| Decisional feedback | Flagging an issue reaches the level that can change the rule directly, not through quarterly reports. | A fully documented loop of correction and rule adjustment. |
Why parallelization produces traceability
In a sequential model, traceability is a separate activity — documented at the end, as a compliance requirement. In a parallel model, each activity produces, by its very nature, a trace.
Traceability shifts from "seeing what the model thinks" to being able to reconstruct what it received, what it produced, who validated it, and what rules were in force at that moment.
This is the only form of traceability that remains valid once the system's internal transparency can no longer be assumed.
A necessary clarification
Parallelizing activities isn't a new principle in technology management. Concurrent engineering has applied it since the 1980s, and agile methodologies carried it into software development.
What has changed is the reason that makes it mandatory. In a context where systems evolve faster than the adoption cycle and internal verification becomes unreliable, it will be the condition under which an organization stays synchronized with what it uses — and can demonstrate, on request, how a decision was reached.
Warnings of this kind will keep appearing, with increasing frequency.
While the pace at which technology develops can't be controlled, how an organization keeps pace with it can be.