When we started using a third-party AI system, my instinct was to treat the compliance work as the vendor's problem. They built it, they had the paperwork, and our contract said they were responsible for the model. I assumed that meant the obligations landed on them.
The failure I kept hitting was subtler than a breach. It was the moment I had to answer a concrete question about our own use of the system: who on our side oversees it, what we log, what we tell the people affected, and what we do when something looks wrong. Those questions are about us, the deployer, not the party that trained the model. A vendor contract cannot answer them, and some cannot be handed to the vendor at all.
So I built a tool that starts from how you actually use an AI system. Paste that description and DutyForge returns an Article 26 deployer-duty pack: a checklist of deployer obligations, markers for the items that are non-transferable, and a list of what to demand from your provider. It sits next to a vendor-vetting step rather than replacing it.
Under the EU AI Act, Article 26 sets out obligations for deployers of high-risk AI systems. These attach to the organisation using a system in its own context, as distinct from the provider obligations that sit with whoever placed it on the market. The broader high-risk framework includes Article 9 on risk management, Article 12 on logging, Article 14 on human oversight, and the Annex III categories that feed classification, plus separate provisions for general-purpose AI models in Articles 53 and 55.
The distinction that mattered to me was non-transferable duties. A contract can allocate costs, warranties, and indemnities between two companies. It cannot make a factual obligation about how you operate disappear. If a duty is on the deployer, the deployer still has it, regardless of what the vendor agreed to. I kept filing everything under "the vendor handles it" and missing that category entirely.
DutyForge marks those items with non-transferable markers, so they are hard to skip, and produces a provider demand list for the things you genuinely should get from your vendor: documentation, information, and cooperation. Separating "ask the provider" from "do it yourself" turned out to be the useful split.
Here is the honest scope. DutyForge is decision-support. It is not legal advice, not a certification, and not a live audit harness. It reads a description of how you use an AI system and returns a checklist, non-transferable markers, and a provider demand list. It does not inspect your deployment, read your logs, check your contract, or verify that any duty has been met.
The output is a draft built entirely from the text you paste. If you describe a use that triggers an obligation the tool does not surface, that is on the input, and I would not treat a clean checklist as a clean bill of health. A marker is a reminder that a duty is likely yours; it is not a legal determination that it applies to you or that you have satisfied it.
The provider demand list is a starting point for a conversation with your vendor, not a claim about what they owe you. The tool does not know your contract. Its job is to stop you from assuming the contract covered something it could not.
I could have built a contract-review tool that parses your vendor agreement and flags clauses. That would need the contract and a lot of legal nuance, and still would not answer the operational questions about your own use of the system. The gap I kept falling into was not a bad clause; it was a missing mental category. A short, structured pack that separates "demand from provider" from "cannot be contracted away" fits that gap and works before any contract exists.
That is also its limit. It is a map of the terrain, drawn from your description, not a survey of your actual deployment. If your current answer to "what are our deployer duties" is "the vendor handles it," DutyForge will at least get the ones that stay with you onto a page.
What is DutyForge?
A decision-support tool that turns a description of how you use an AI system into an Article 26 deployer-duty checklist, with non-transferable markers and a provider demand list.
Does it check my deployment or my contract?
No. It works from the text you paste. It does not read logs, inspect the system, or review your vendor agreement, and it is not a live audit harness.
Can it tell me whether I am compliant?
No. It is not legal advice and not a certification. Which obligations apply and whether you meet them are determinations the tool does not make.
What does "non-transferable" mean here?
A marker on a checklist item that a duty of this kind stays with the deployer and cannot simply be shifted to the provider by contract. It is a prompt to look, not a legal conclusion.