Discovery call →
Deutsch
Discovery call →
Deutsch
AI has long been writing code in your team – faster than reviews can keep up. We lay an AI governance framework over it that records your rules on testing, security and data protection in machine-readable form and catches breaches at the moment of writing rather than months later in an audit. The framework is called Intentron. Three companies stand behind it: PRODOC Digital, FrontEnd IT and Owlist GmbH as the author.
The sequence is the same everywhere: you tell the AI “build me X”, and ten minutes later code is running. Three weeks later nobody remembers why a decision was made that way. You ask about a bug – the AI no longer has the context. A new feature breaks an old one. And which version was last stable is no longer clear either.
In a weekend project that is annoying. In a regulated industry it is a business risk. Because there it is not enough for the software to run – it has to be documented, checkable and compliant. And the real risk is its invisibility: AI quickly delivers something that works. Whether your security thresholds, data protection rules and architecture requirements were kept is not something you can tell from the result.
The finding comes late – in the security review or the data protection audit, once production software has long been in use. By then a mountain of three debts has grown out of sight: technical debt (the product becomes hard to maintain), compliance debt (rules were never checked) and security debt (vulnerabilities were never caught). The pace the AI gains, you pay back later with interest.
In regulated companies a decision is rarely made by one person alone. So the framework answers the question of benefit separately for each role – with a mechanism, not a promise.
“How do we get faster without chaos?” Every change runs through the same life cycle: intent, story, build, check, merge, review. What went wrong yesterday is recorded in the sprint review and fed back when the next story is cut – the team does not repeat known mistakes a second time.
“Does code come into being without a documented intent?” No, because without a specification file the commit does not go through. On top of that there is a gate against documentation drift: if architecture and governance documents diverge, it blocks. Out-of-date documentation is technical debt in prose – here it becomes measurable rather than tolerated.
“Will I hold up in the audit?” The evidence is produced while the work happens, not gathered afterwards on request: check reports per run, documented intent per change, enforced sign-offs on security-sensitive paths. An audit tool reconstructs the chain from the idea through the specification to the commit.
“What business risk am I taking?” You keep the pace of AI and reduce the risk that non-compliant software is first noticed in an audit – at the point where fixing it is expensive. The strictness scales with the risk: an experiment runs light, a regulated production system runs strict. You set that per project, not once for everything.
What that costs day to day is one section further down, in the “Effort” row – honestly, with the price of the alternatives beside it.
Your real comparison is not one framework against another. It is three attitudes you will meet in any development organisation – and a fourth option.
| AI ungoverned | Ban AI | Code reviews alone | AI with governance | |
|---|---|---|---|---|
| Pace | High | Low – your competitors use it anyway | High, until the review becomes the bottleneck | High |
| Auditability | None – the intent is written down nowhere | Given, but dearly bought | Depends on who looks, and when | Specification before every commit, audit trail back to the intent |
| Audit readiness | Evidence is hunted for afterwards | Inconspicuous, because little gets built | Reviews are rarely documented in a verifiable way | Evidence is produced while the work happens |
| Knowledge lost when people leave | Complete – the why was only in someone's head | Unchanged from today | Partly cushioned | Intent, decision and check result stay in the project |
| Effort | Apparently zero; the interest falls due later | Forgoing the productivity gain | Grows with every AI-generated pull request | Set up once, after which the checks run alongside |
“Ban AI” is not a straw man in this table: it is a legitimate decision, as long as it is taken deliberately and enforced. In practice it rarely holds – developers then use the tools out of sight of IT.
Intentron is an AI governance framework for software development. It is not an autonomous AI that builds away on its own, but a guided assembly line: first the intent is recorded, then the AI writes the code, and before anything is taken into your main branch, automatic controls for security, quality and data protection run. Whatever fails the check does not get through.
Technically it consists of encapsulated working instructions for AI development tools, which together enforce a controlled sequence, and of a set of checking gates that hook into the tools themselves. The governing core deliberately does not sit in the tool but in the project contract: a file in which your rules are set down in machine-readable form.
The author and rights holder is OWLIST GmbH (Switzerland). The manufacturer's product site is intentron.ai. PRODOC Digital introduces the framework at client sites as a delivery partner.
Release v0.42.0 – figures as at 07/2026. All three can be counted in the repository; we give them with a date so it stays visible when they were last checked.
What is to be achieved, and why? That question is answered before anyone touches code. It is the anchor to which every line can later be traced back.
The intent becomes a bounded task with a scope, an effort estimate and a definition of done. Known anti-patterns from earlier sprints feed in here automatically.
Only now does the AI write code – within the bounds of the specification. A filter takes hold before the writing: credentials and unsafe patterns never reach the disk in the first place.
Linting, static security analysis, dependency checking and test coverage run automatically. Without a linked specification the commit is blocked – and equally without a passing check.
In continuous integration the same checks run once more – server-side, and therefore not bypassable from a local machine. Only after that does anything reach the main branch.
At the close, the work is checked against the quality goals and what was learned is recorded. This learning loop is why the same mistake does not arise afresh in every sprint.
There is no one big check at the end, but several controls along the way. If one fails, the next takes hold. What matters is that the last one does not run on a laptop.
A filter inspects every write the AI makes before it is carried out, catching passwords, tokens and known unsafe patterns. This prevents the case where a key is first noticed in the repository – and by then it is in the history.
Linting, static security analysis and the check for invented or vulnerable dependencies run at the commit. This prevents hallucinated package names and known vulnerabilities from reaching a pull request at all.
The same checks run again server-side, as a required status check before the merge. This prevents the one case that makes local checks worthless: someone skipping them under time pressure.
For companies under MDR, DORA, MaRisk or KRITIS, the question of the operating model is not a technical preference but part of the compliance file.
The framework is forge-flexible: it runs on GitHub just as it does on self-hosted Gitea or Forgejo instances. Code, issue tracking and CI can therefore stay entirely in your data centre. On-premises language models are provided for – there is no compulsion to use a US vendor. Data sovereignty here means not only where the data sits, but which law governs it.
A versioned control catalogue for the GDPR, the German BDSG and the Swiss nDSG is worked through deterministically and yields a result for each item. Where a change touches paths carrying personal data, the framework requires a data protection sign-off before it goes through.
A catalogue for the EU AI Act is available as an extension. Independently of that, the tamper-evident audit trail feeds directly into the documentation duties: for every change, the intent, the check result and the sign-off are held immutably in one defined place – instead of in chat histories.
Every project carries a confidentiality level. It governs which models and endpoints are permissible for which data. From the level “confidential” upwards, enforcement is designed to sit with the platform rather than with the good behaviour of an individual workstation.
We recommend nothing we do not run ourselves. The page you are reading is built under the same procedure – verifiable against concrete artefacts in the repository:
The second and more telling piece of evidence is an omission: this project runs at the middle governance level, but with documented exceptions. Four gates that yield no insight on a static website without runtime logic are expressly switched off – with a reason, and with a note on when they would need to be added.
That is exactly the point at which a rule set shows whether it is any good: it has to be adjustable to the risk without anyone quietly bypassing checks.
The strictness is not a one-way street. You start light and tighten once the prototype becomes a product.
| lite | standard | heavy | |
|---|---|---|---|
| Intended for | Throwaway scripts, learning projects, experiments without consequences | Client work, small production services, serious solo projects | Regulated, revenue-critical or long-lived systems |
| Always active | Project contract, mandatory specification, basic linting | additionally security gates, sensitive paths, learning loop | additionally test coverage, branch protection, mandatory review |
| Depth of evidence | Intent documented | Check reports per run | an unbroken audit trail with sign-offs |
| Typical trigger | Nothing worth protecting, no consequences | External clients or several developers | Personal data, payment or authentication logic, regulation |
Where several triggers apply at once – regulated and personal data and revenue-critical – heavy is the right answer. Making that call is part of the governance assessment.
Intentron is not an open-source project to try out. The repository is private, and the rights holder is OWLIST GmbH. Anyone wanting to use it gets access through a partner and pilot model.
The usual route runs through a governance assessment to a bounded pilot project; only then do you decide about lasting use.
Intentron is marketed jointly.
Goslar, Germany. Introduces the framework at your site, translates your regulatory requirements into gate configurations and trains your team. Your point of contact is Stefan Weimar, TÜV-certified AI consultant.
Böblingen, Germany. Brings development and operations capability, and runs the infrastructure if you would rather not host the framework yourself. frontend-it.de
Switzerland. Develops the framework and holds the rights to INTENTRON. The manufacturer's product site: intentron.ai · owlist.ch
The last point is the most important: the framework makes human judgements demonstrable – it does not replace them. Where nobody decides, no gate helps either.
The effort arises once, at setup: your rules on testing, security and data protection are written into a machine-readable project contract. After that the checks run along in the background and speak up only when they find something. The strictness can be set per project – a throwaway prototype runs at the lightest level, a regulated production system at the strictest.
Yes – but a specification here is not a requirements document. It is a short file with intent, scope and a definition of done. It comes into being in the same step in which the task is described anyway. What you get back: six months later it says there why a decision was made that way. That is precisely the answer that is otherwise missing in an audit and at every handover.
That is a fair concern and the most common reason rule sets fail. Two things help. First, the strictness is adjustable – you begin at the level that matches the risk and tighten only once the prototype becomes a product. Second, documented exceptions are supported: gates that make no sense for your project may be switched off with a reason. We do exactly that on this website.
The opposite: you win it back. Without a framework the AI quickly delivers something that runs – whether your rules were kept is not something you can tell from the result. With one, the intent is fixed before the first commit, every change goes through the same checks, and an audit trail leads from every line back to the original intent. The expert judgements stay with your people – the framework makes their work demonstrable, it does not take it off their hands.
Yes. The decision you are making is not a technical one: how strictly should the checks bite, which paths need a human sign-off, who signs off security and data protection? These adjustments are described in business language. For every role – board, CTO, CIO, CISO – there is a dedicated reading of under ten minutes that answers exactly their questions.
No, and that matters. The framework replaces neither an external penetration test nor a legal assessment of your particular case, and it guarantees no freedom from defects. What it does is make sure breaches are caught early and that the evidence for an audit is produced during the work rather than afterwards. The difference is the one between “we hope it fits” and “we can show that it fits”.
No. Intentron is not a public open-source project – the repository is private, and the rights holder is OWLIST GmbH. Access runs through a partner and pilot model. The usual route is a governance assessment, out of which a bounded pilot emerges; only then do you decide about lasting use.
No. The governing core sits in the project contract, not in the tool: rules, specifications, gates and evidence remain in place when you change development environment. The same holds on the infrastructure side – the framework runs on GitHub just as it does on self-hosted Gitea or Forgejo instances, and on-premises language models are provided for.
Two days, from €5,000 plus VAT. You get a gate map of your existing repository, a reasoned maturity-level recommendation, a roadmap of measures and a proposal for the first pilot scope. The one prerequisite is read access to a repository – we need nothing more.
Before a framework can take hold, the team has to command the tools. In the developer workshop your team builds a working prototype in one to three days – with your code, in your infrastructure.
More on our workshops →When the data must not leave the building: consulting, architecture and implementation of AI systems that run entirely on your hardware – no cloud, no recurring API costs.
More on on-premises AI solutions →