What is an AI solution architect?

An AI solution architect designs the technical blueprint for an AI system before the build starts: which model does the work and how replaceable it is, where the data comes from and how it stays current, how the system authenticates into the estate you already run, what it writes to the audit trail, where a person can stop it, and what it costs per transaction at full load. In an organisation of a few hundred to a few thousand staff the role is rarely about inventing a new stack. It is about deciding how one new, non-deterministic component is allowed to sit inside a landscape that already works and already has to stay compliant.

The title overlaps with four roles most IT organisations already have: the enterprise architect, the solution architect, the MLOps or platform engineer, and whoever your ICT partner fields as a lead architect. The difference is not seniority. It is which decisions each of them owns, and which of those decisions become expensive to reverse once the first system is live.

What does an AI solution architect actually deliver?

The deliverable is a document you can hand to a builder and to an auditor, not a diagram. Six artefacts recur.

• A system context. Which existing systems the AI reads from and writes to, named rather than generic: the ERP, the CRM, the WMS or TMS, the document store, the identity provider. Each flow has a direction and an owner.
• A data design. Where the retrieval or training data comes from, who owns it, how often it refreshes, and what happens to a record when it is corrected or deleted upstream. Most retrieval failures in production are this, not the model.
• An integration design. The interfaces, the failure behaviour of each one, and what the business does while an interface is down. An AI feature that silently returns stale answers during an outage is worse than one that refuses.
• A control design. Identity and authorisation for the actions the AI takes in its own right, the events it logs, the points where a person approves, and the thresholds that route a case to a human instead.
• An evaluation design. What working means in numbers, measured against a held-out set maintained by somebody other than the person who built it.
• A cost and capacity model. Cost per transaction at expected load and at three times expected load, and which component you would swap first if a vendor changed its pricing.

A useful test: if the document does not name your systems, it is a template.

How is an AI solution architect different from your enterprise architect?

The roles separate on ownership rather than rank.

• Enterprise architect. Owns the target landscape and the standards a new system has to meet. Answers whether this belongs in the estate at all, and against which principles.
• Solution architect. Owns one system's design inside those standards. Most are very good at deterministic systems. AI introduces failure modes that classical solution architecture was not built for: a component that is right most of the time, degrades quietly rather than breaking, and cannot be unit-tested the same way.
• AI solution architect. Owns exactly that difference. Non-determinism, data freshness, evaluation, model replaceability, and the controls that make a probabilistic component auditable.
• MLOps or platform engineer. Owns the runtime once the design exists: pipelines, deployment, monitoring, drift.
• Your ICT partner's lead architect. Owns the estate the system lands in: network, identity, endpoints, and the service desk that will take the calls.

In a 250 to 5,000 FTE organisation the first two usually exist and the third usually does not. So the question is rarely whether you need an architect. It is who owns the part that is genuinely new.

Where does an AI architect sit next to your ICT partner?

Alongside, not instead. Crux Digits is an AI supplier and not an ICT partner: we do not sell systeembeheer, infrastructure, hosting or a service desk, and we assume you already have those, in-house or from a supplier you have worked with for years. That assumption shapes everything below.

The seam between the two is where mid-market AI projects actually stall, and it comes down to three decisions nobody assigns:

• Who issues the AI's credentials, and who rotates them. An agent acting in its own right needs an identity in Entra ID or your equivalent, with its own permissions and its own expiry. A shared service account borrowed from a developer is the most common shortcut and the one that shows up in the next audit.
• Whose monitoring sees it fail first. Your ICT partner watches availability. An AI system can be fully available and wrong. Somebody has to own the second signal, and the blueprint has to say who and on what alert.
• Who the user calls when the output is wrong but the system is up. If that route is not designed, it defaults to the service desk, which cannot fix it, and the feature quietly stops being used.

Settle those three in writing before the build, and the supplier relationship tends to run itself.

What does the architecture have to get right that a pilot never tests?

A pilot runs on a clean extract, with a friendly user, at low volume, on last month's data. Six things only appear afterwards, and all six are architecture rather than model choices.

• Identity and permissions. In the pilot the builder's own account had access to everything. In production the AI must see exactly what the requesting user is allowed to see, which is a design decision about how the request carries its context.
• Data freshness. The pilot index was built once. Production needs a defined refresh, and a defined answer for records that were corrected or deleted upstream.
• Concurrency and cost at load. Per-transaction cost that is trivial at twenty a day is a budget line at two thousand.
• The exception volume. The cases the pilot skipped are the ones that decide whether staff keep using it.
• The audit trail. Which input produced which output, under whose authority, retained for how long.
• Model replaceability. Vendors deprecate models and change prices. If swapping one means a rewrite, that is an architecture defect, not bad luck.

Which EU AI Act duties land on the architecture rather than the policy?

The AI Act, Regulation (EU) 2024/1689, entered into force on 1 August 2024 and applies in stages. The Article 5 prohibitions and the Article 4 AI literacy duty have applied since 2 February 2025, the general-purpose model obligations since 2 August 2025, and the Article 50 transparency duties since 2 August 2026. The Digital Omnibus on AI, Regulation (EU) 2026/1744, adopted on 8 July 2026 and in force since 27 July, moved the high-risk duties of Chapter III Section 2 to 2 December 2027 for standalone Annex III systems and 2 August 2028 for AI embedded in Annex I regulated products. The dates moved. The obligations did not.

Four of Articles 9 to 15 are design decisions rather than policy statements, which is why they belong in the blueprint and not in a compliance annex written later. Article 10 sets data governance requirements for training, validation and testing data. Article 12 requires automatic recording of events over the system's lifetime. Article 14 requires the system to be built so a person can oversee and intervene. Article 15 covers accuracy, robustness and cybersecurity, with accuracy levels declared in the instructions for use.

You cannot add an audit trail to a system that never emitted one, and retrofitting a human-oversight step into a workflow people have already learned to trust is a change project rather than a patch. Most mid-market AI is not Annex III high-risk, and it is worth saying so plainly. But recruitment and credit scoring are on that list, and an organisation of this size often runs one of them. None of this is legal advice.

What does the Cyberbeveiligingswet change for an AI system?

The Dutch implementation of NIS2, the Cyberbeveiligingswet, entered into force on 15 August 2026 and sets requirements for the digital resilience of more than 8,000 organisations delivering essential or important services. It brings a registration duty in the entity register, a zorgplicht (a risk analysis and appropriate, proportionate measures to secure network and information systems) and a reporting duty: significant incidents go to the CSIRT and the supervisor as soon as possible and in any case within 24 hours. The board approves the measures and supervises their implementation.

The architectural consequence is narrow and concrete. A 24-hour clock is only meetable if the system tells you something happened. An AI component that holds a service account into your ERP, reads documents from the file share and emits nothing to your SIEM is a blind spot in an estate that now carries a statutory reporting duty. Whether a given AI system falls in scope is a question for your CISO and your counsel. Whether it emits what an incident report would need is a question for the blueprint, and it is much less expensive to answer before the build than after.

Do you hire, contract or borrow an AI solution architect?

Read from the top. The first block that describes you is usually the right answer.

• Borrow one for a fixed scope. One or two systems planned, nothing in production yet. What you need is a review measured in weeks, not a headcount. Crux Digits bills advisory work, architecture reviews and guidance for an in-house team at €150 an hour excl. VAT; the €2,500 AI Audit & Strategy is the packaged version of the same work.
• Contract an interim. A programme with several systems over twelve to eighteen months and no internal candidate. More expensive per day, no hiring risk, and knowledge transfer can be written into the assignment rather than hoped for.
• Hire. Three or more AI systems live or planned, and AI on the roadmap indefinitely. For an order of magnitude, SalaryExpert's modelled figures put an AI solutions architect in the Netherlands at roughly €119,500 a year on average and about €132,400 at senior level. Modelled salary data is an order of magnitude, not a quote.
• Do nothing yet. Nothing in production, no named process, no internal owner with hours in their week. An architect with no system to design writes a document nobody opens.

Where does Crux Digits fit?

We design and build AI systems alongside your existing IT organisation and your existing ICT partner, from Utrecht, with one named expert who stays on the work rather than a rotating team.

Three steps, three fixed prices, each scoped in writing before work starts: the AI Audit & Strategy at €2,500 over one to two weeks, a Production-ready MVP at €20,000 over four to six weeks, and a Production Launch from €50,000 from eight to twelve weeks, all excl. VAT. Advisory, architecture reviews and guidance for your own team are billed hourly at €150 excl. VAT. Build work never is.

Go on to the MVP within 60 days and the €2,500 audit fee is credited in full. Everything produced is yours at handover, the code included. And if the honest answer is that a setting in software you already pay for does the job, the audit says so and saves you the build.