Question 1

Why do most AI projects never reach production?

Accepted Answer

Because the pilot was built in conditions production does not have.

A proof of concept runs on hand-cleaned data, on one machine, with no integration to the systems the business actually uses. It has no error handling, no monitoring, no logging and no role-based access control. All of that has to be added afterwards, and that is where projects stop.

Production data is inconsistent. Response times have to stay under a second. Security requires least-privilege access, so an employee cannot prompt their way to a colleague's salary. The underlying mistake is treating it as an AI problem and building down from the model, instead of treating it as a systems architecture problem and building up from the infrastructure.

Cases

Question 2

What actually blocks AI in Danish companies?

Accepted Answer

Missing technical competence and poor data quality. In that order.

Most organisations that stall have no shortage of strategy. What they lack is the engineering to turn it into working software - data pipelines, cloud architecture, access control, operations. Without that, the usual outcomes are analysis paralysis or an off-the-shelf product that cannot be integrated with anything.

The second blocker is the state of the data. Information sits across ageing ERP systems, CRM databases, closed file shares and unstructured PDFs. If it cannot be collected, cleaned and made available through reliable pipelines, the model will answer from whatever it happens to find. Compliance uncertainty is a real third: fear of GDPR exposure and the EU AI Act stops projects before they are scoped.

Question 3

Why do RAG systems fail in production?

Accepted Answer

Because retrieval is usually naive, and the model is blamed for it.

Retrieval-augmented generation lets a model answer from your own documents. The concept is sound. The failure is almost always in the retrieval layer, not the model. Pure vector similarity assumes the question and the answer share the exact same terminology. In a real company they rarely do: someone asks how to escalate a P1 incident, and the document that answers it was written in 2019 and calls it a severity-one.

The second failure is chunking. Long documents get cut into fixed-size pieces, which separates a conclusion from the conditions it depends on. The retrieved passage is correct and useless at the same time. Fixing both means hybrid retrieval - keyword search alongside vectors - reranking the results, and chunking that respects document structure.

Question 4

What does the EU AI Act require right now?

Accepted Answer

The transparency rules already apply. The high-risk rules were deferred to December 2027.

The Act sorts systems by risk. Since 2 August 2026, anything that interacts with people has to say so, and synthetic output has to carry machine-readable marking. The Digital Omnibus of 27 July 2026 then deferred the high-risk requirements to 2 December 2027, and to 2 August 2028 for AI embedded in products already covered by product safety law.

The obligation most companies have missed is AI literacy: any organisation using AI tools, including ordinary ones like ChatGPT or Copilot, has to support its staff in using them responsibly. Deferred is not cancelled either, so the documentation is cheaper to build in now than to bolt on later. We keep a full reference on what the Act asks of a development team, with every date sourced.

EU AI Act

Question 5

How do you handle GDPR and personal data in generative AI?

Accepted Answer

A lawful basis, a processing agreement that forbids training on your data, and minimisation before anything is sent.

GDPR applies to AI exactly as it applies to everything else. The processing agreement has to state where data is stored and must explicitly prohibit the supplier from using your data to train their own models. Anything intrusive needs an impact assessment before it goes live, not after.

The engineering answer is data minimisation: strip or pseudonymise personal data before inference, so names become identifiers and sensitive fields are masked before the prompt leaves your network. Models that keep training on user input are a particular risk - personal data can end up encoded in the weights, which makes the right to erasure impossible to honour. Hosting inside the EU, or running open models on your own infrastructure, removes most of the problem.

Question 6

What is Shadow AI, and why is it a security risk?

Accepted Answer

Staff using unapproved AI services for real work. Your data leaves, and nobody logs it.

While leadership debates strategy, most of the workforce has already adopted the tools. Someone pastes a customer list, board minutes, source code or a draft contract into a free assistant to save an hour. At that moment the data has left your security perimeter, and you have no record that it happened.

Blanket bans make it worse - they push the practice onto personal devices where nothing is visible. The workable answer has two halves. Set data classification rules and block unsanctioned services at the endpoint. Then give people an internal tool that is genuinely good enough that reaching for the public one stops being tempting.

Services

Question 7

How do you prove ROI and total cost of ownership?

Accepted Answer

By costing the whole system, not the model licence.

The common mistake is budgeting for API calls and nothing else. The real cost of ownership includes hosting, storage, monitoring, security updates and the engineering time to keep it running. A project that looked cheap at the pilot stage becomes expensive precisely when it starts being useful.

On the return side, the gains that hold up are in knowledge work: time spent searching for information, assembling data and drafting text. Measure against the hours currently spent on the work AI would absorb, not against a projected transformation. Two things reduce the financial risk structurally - a fixed price agreed before any code is written, and a perpetual licence to the code so there is no recurring fee attached to it.

AI Readiness Assessment

Question 8

Who owns the source code and the IP?

Accepted Answer

You can use, change and move everything we build. The licence is perpetual, and we keep the copyright.

Danish copyright law leaves the rights with the supplier unless the contract says otherwise, so this gets written down rather than assumed. We use the same construction as the public-sector K-agreements and the IT-Branchen standard terms: you get the licence, we keep the copyright.

What you get

A perpetual, unrestricted licence to everything built for you. Run it, change it, build on it, with your own developers or any other supplier. No time limit, no geographic limit, and it continues after the engagement ends.

What we keep

The copyright, and the right to reuse the general knowledge, know-how, tools and components from our work. Your data, your content and anything confidential stay yours, and are removed before anything is reused elsewhere.

Third party

Open-source and third-party components keep their own licences. We list every one we use.

That split is part of why the price is what it is: the foundation is already built. You can bring operations in-house or move to another partner at any point, and you can show and audit the code when a regulator or an auditor asks. The licence is yours at handover, or at the point of payment for anything paid in advance, and it continues after the engagement ends.

Services

The questions worth asking before you build

Getting AI into production

Security, law and data

Money and ownership

Want these answered for your business?