The project we were given, BygBot, was already under way at Region Sjælland when we arrived: an external supplier, a defined user group and a launch planned for spring 2026. Our task was to understand it well enough to contribute. What the first meetings revealed instead were the tensions: who owned the project, who the primary user really was, and where the supplier’s delivery ended and the region’s requirements began. Then the project’s key person left, and it became clear that one person had been holding the whole network together. Without them it was no longer a place an outside group could work.

So we changed course. We had met the actors and gathered the material, and the material pointed to a neighbouring department: Udbud & Indkøb, the procurement office that runs the region’s IT tenders under a dense body of rules, from the Public Procurement Act to GDPR, the NIS 2 directive and green public procurement. They did not lack knowledge. They lacked a way to keep it all in order.

The workshop was the turning point. Mapping the consultants’ journey with them made one thing clear. The difficulty is coordination: many actors, many documents, many rules. The hardest part is writing the requirements about GDPR, NIS 2 and GPP correctly and consistently, every time. Our How might we became: how can relevant legislation such as GDPR, NIS 2 and GPP be built correctly into the requirement specifications?

Just as telling was what nobody asked for. Nobody wanted decisions made for them. AI came up again and again as a sparring partner, something to help with an overview and to gather valid data, a way to raise quality rather than just speed. That settled the direction: not a system that takes over the work, but one that supports it, inside the workflow the consultants already had.

We sketched two directions and put both in front of the users. The knowledge bank would let consultants find and reuse earlier tenders and lessons learned. The junior consultant would read a draft, flag what was unclear and suggest how to fix it.

The junior consultant won. A sparring partner close to the task, reviewing the consultant’s own draft before it reaches legal review, was where the need was greatest. The knowledge bank was welcomed too, but the regions were already building one together. That first round of feedback decided what KravTjek would be.

The functions were the easy part. The harder question was how much the language model should do: write parts of the specification, or help the consultant write them? Be a system of its own, or sit close to the programs they already use? In a job that already means working across several systems, a new one can add complexity instead of removing it.

The second feedback round settled it. The visual overview worked, described as nice and intuitive, and so did the AI dialogue, precisely because it sparred rather than decided. KravTjek therefore suggests wording, pulls requirements from the law text and answers questions about NIS 2 and GDPR, and stops there. A system that writes complete legal requirements takes too much judgement away from the person who is responsible for them.

We pitched KravTjek through a concrete scenario, a requirement specification for IT client equipment, using the prototype as a probe rather than a finished system. The department found it more realistic and more usable than earlier AI initiatives, and named the narrow scope as its strength: much more realistic and faster to execute on, as one consultant put it. The value lay in finding one bounded moment in the work where AI genuinely helps, not in automating the tender process.

The blind spot is that KravTjek is a design proposal. It has not been legally reviewed or tested in operation, and the prototype simulates a workflow without friction. We could not test how a real language model handles poor input, complex hardware specifications or invented citations. The next step should not try to prove time savings. It should be a small, critical pilot that tests exactly those things, and whether consultants keep their own judgement when the system helps.

Upload a draft specification in the formats you already use, and get an overview: which requirements need attention, and how far the work has come.

• The specification split into work areas, with progress per area.
• Every requirement reviewed: ambiguities, gaps and suggested clarifications that can go straight into the text.
• Bounded sparring against NIS 2, GDPR and GPP, against a source rather than an open chat.
• Never approved, never a legal ruling. Nothing closes without the consultant’s own status mark.
• Alongside Excel and Word rather than instead of them, so it can be introduced gradually.

The consultant keeps ownership of the specification, and spends less energy on building an overview and more on making decisions.