The easy answer takes a few seconds. The provider is secure, customer data is not used to train the model, and there is a privacy policy on the website. That sounds reassuring until the DPO asks one very simple question.
If a customer asks us to erase their data tomorrow, do we really know where all of it went?
The conversation changes at that point. Someone needs to know what remains in the Agent memory, its checkpoints, its records, its pending requests, and the systems connected to it. Someone needs to prove which version of the Agent made a decision, why it called a tool, and who approved a sensitive action. If something goes wrong, saying that the model misunderstood the prompt is not an acceptable answer.
This is where a good demo stops being a product. It is also the moment I had in mind when I built Spectre.
The demo is not the product
Many Agent frameworks are excellent at getting a demonstration running quickly. Connect a model to a few tools, add memory, and the system can soon answer questions, find information, and take action. That is useful, but for a business it is only the beginning.
A CEO has to consider what happens to customer trust if the Agent exposes information it should never have known. A CTO needs to understand who owns system state, how changes are approved, and whether an erasure remains valid after a restart. The security lead wants to know whether an old process can write outdated data. The DPO needs a precise answer when a person exercises a legal right.
These questions are not about the quality of the conversation. They are about the accountability of the company.
Spectre 0.3.3 is a governed runtime for Agents that need to live inside real products and business processes. The model can understand, propose, and assist. It does not own final authority over state, credentials, or actions that have consequences in the world. That authority remains with the application and therefore with the organisation operating it.
For anyone buying or deploying an AI solution, that distinction matters far more than another feature in the demo.
Privacy starts with what you choose not to keep
The GDPR repeatedly returns to principles such as minimisation, storage limitation, security, and data protection by design. In business terms, the message is direct. If information is not needed, it is better not to collect it. If it is needed, the company should know why it exists, where it lives, and how long it will remain available.
Spectre applies this idea to the structure of the Agent itself. Its Journal records the path of decisions without copying the whole conversation, sensitive action arguments, complete tool results, or raw provider errors by default. It keeps what is needed to understand system behaviour while leaving the company in control of any decision to collect more when there is a valid reason.
This is a practical distinction. A record designed for assurance should not automatically become a second store of personal data. Fewer unnecessary copies mean less surface to protect, fewer places to inspect, and fewer surprises when an access or erasure request arrives.
Erasure has to mean erasure
Erasure is one of the points where many prototypes reveal their limitations. Deleting a database row may look sufficient, but an Agent often exists in several places at once. It can have active state, a checkpoint, recorded events, receipts waiting for delivery, and processes still working on an older version of the data.
Spectre 0.3.3 introduces a governed erasure procedure for inactive Instances. It first identifies the subject precisely and shows what falls within the operation. It then removes configured core data in a controlled order, creates proof that does not reveal the erased content, and leaves a durable signal that prevents an outdated process from recreating that state.
That last detail matters. Erasure is not real if an old process can bring the data back seconds after the company said it was gone.
Spectre also verifies that the operation remains isolated to the correct identity, that it can be repeated safely, and that a concurrent write cannot defeat the erasure. These problems are almost invisible during a presentation, but they become essential when an Agent works with customers, employees, patients, or citizens.
Of course, no runtime can discover every place where a company has copied data. Spectre governs what it can see and what its adapters declare. The application remains responsible for external memory, telemetry, exports, provider records, replicas, and backups. The important change is that there is now an explicit and verifiable boundary rather than a vague promise hidden in application code.
The model proposes, the company decides
When an Agent can send a communication, change an order, open a confidential document, or initiate a payment, telling it in the prompt to ask for confirmation is not a control system.
The model may misunderstand the request. An update may change its behaviour. An attack may try to persuade it that approval has already happened. This is why authority does not live inside the prompt in Spectre.
The model proposes an action. Policy and the deterministic lifecycle decide whether that action can proceed. When a human or business decision is required, the system can wait for it without freezing the entire conversation. Approval comes from a source controlled by the application, not from a sentence generated by the model itself.
For a CEO, this provides a more credible basis for saying that sensitive decisions remain under human control. For a CTO, it creates a boundary that can be tested, observed, and connected to the authorisation systems the company already uses.
The principle is simple. Intelligence may live in the model, but accountability must remain with the organisation.
Compliance needs evidence
During an audit, saying that the team follows a good process is not the same as proving it.
Spectre treats the operational configuration of an Agent as an immutable, versioned Definition. When a model, policy, prompt, capability, or approval rule changes, the business can know which version was evaluated and which one was actually activated. The Journal and receipts then connect decisions to the correct state and Definition without exposing secrets or unnecessary personal content.
This makes it possible to reconstruct a question that eventually appears in every serious project. What did we know, which version was active, and why was the system allowed to act?
With Spectre observation and reproduction tools, including Spectre Lab, behaviour can be studied and compared without relying on the memory of whoever happened to be present. A problematic version can be stopped and an earlier Definition can be restored through an explicit process. For the business, that means faster investigations, safer changes, and more concrete conversations with security, legal teams, customers, and auditors.
Freedom from a provider is also a governance decision
In Europe, data location, supplier terms, and international transfers can change a commercial decision. A solution deeply tied to one model or one service may feel convenient today and become expensive tomorrow.
Spectre leaves storage, credentials, authorisation, and external action under host control. Models and infrastructure can be replaced behind verifiable contracts without giving them ownership of the Agent canonical state. This does not remove the work required to assess a new supplier, but it makes that choice possible without rebuilding the entire product.
For a CTO, this means greater architectural freedom. For a CEO, it reduces a dependency that can affect margins, operational continuity, and access to regulated customers. For an agency, it creates a foundation that can be adapted to clients with different requirements for retention, data residency, and approval.
GDPR, the AI Act, and ISO ask a similar question
The GDPR, the AI Act, and ISO standards are not the same thing. GDPR protects people when personal data is processed. The AI Act introduces obligations based on risk and, where relevant, places particular importance on risk management, logging, human oversight, robustness, and security. Standards such as ISO/IEC 42001, ISO/IEC 23894, ISO/IEC 27001, and ISO/IEC 27701 help organisations build management systems for AI, risk, security, and privacy.
Yet when these perspectives enter a real project, they reveal a common need. The company must know its system, assign responsibility, control change, limit data, maintain oversight, and produce credible evidence.
Spectre 0.3.3 does not automatically make an organisation compliant, and it does not provide an ISO certification. It does offer a technical foundation that speaks the same language as governance processes. The Journal that helps explain an incident can also support an internal review. The Definition that controls an update can provide evidence for change management. The separation between the model and authority can support the design of human oversight.
This does not mean that one piece of evidence satisfies every requirement. It means the company does not need to build a different technical system every time it must demonstrate another aspect of the same control.
The value for a CEO and CTO
The value of this architecture is not measured only in code. It appears when a security review takes weeks rather than months. It appears when an enterprise customer receives precise answers, when the DPO does not have to chase hidden data across five services, and when an unsafe update can be stopped without shutting down the whole product.
Most of all, it appears in the cost the company avoids. Adding governance after an Agent is already connected to customers, systems, and business processes is far harder than designing it from the beginning. What looks like a technical detail in a demo can become a blocked sale, a loss of trust, or a board level risk.
This is why I do not claim that Spectre is better for every AI experiment. If the goal is to test an idea in an afternoon, simpler tools exist. But when an Agent must remain active, process personal data, or create real effects, the ability to govern it is not an optional addition. It is part of the product.
Technology does not replace responsibility
Spectre does not choose the lawful basis for processing, write the privacy notice, perform the impact assessment for the DPO, or decide whether a system belongs to a category under the AI Act. It does not configure provider retention, approve international transfers, train employees, or award an ISO certification.
Those responsibilities remain with the organisation and the professionals supporting it. Spectre helps turn their decisions into technical controls that are real, observable, and reproducible.
The question to ask before bringing an Agent to market is not only how well it can talk. It is who can stop it, who can authorise it, how its data can truly be erased, and what evidence remains after a decision.
In Europe, a credible Agent must do more than work. It must earn the trust required to enter the business. Spectre 0.3.3 was built for exactly that transition.