A Dutch housing corporation's IT estate is already governed by sector agreements: CORA for architecture, five Aedes data standards for data, and a covenant that around thirty software suppliers have signed. Your AI supplier has signed none of them. That is not a reason to reject the supplier. It is a reason to put in the contract what covenant membership would otherwise have given you.
This is written for the informatiemanager, IT manager or CIO of a large corporation, and the size band matters here more than usual. Aedes counted 30,630 people employed across the sector at the end of 2025, and the Autoriteit woningcorporaties counts 261 corporations holding 2.4 million dwellings. That averages roughly 117 people per corporation, and that is the generous reading, since the monitor was filled in by 186 corporations covering 86.4 percent of the sector's units. So the 250 to 5,000 FTE reader this is written for is the corporation above roughly 20,000 homes, or the shared service organisation that runs IT for several of them: the places with a named information manager, a change calendar and an internal audit, rather than one generalist who also owns the phone system.
Which standards already govern your IT estate?
Two things sit above your application landscape, and neither is law. CORA, the Corporatie Referentie Architectuur, describes the standardised business operations of a corporation and helps you see which user functions and application components you actually need; CorpoNet develops and manages it, its online edition runs from version 4.0, and its core team has added a sector-wide capability map with knowledge partner Solventa. VERA, the data model, has been managed by Aedes Datastandaarden since 1 April 2023 and is developed jointly by corporations and suppliers.
Underneath those sit the five standards on the Aedes Datastandaarden roadmap: DIV-it for the digital income statement used in allocation, ILS-woco for real estate information, RGS-woco for the financial administration, DICO-woco for maintenance messages (currently at onderhoudsberichten version 006) and VERA. Your ERP supplier works to these. Your allocation platform works to these. The whole reason your last migration did not need a custom interface for every counterparty is that these exist.
Why is your AI supplier not in the Aedes covenant?
Aedes has a covenant with suppliers, the Samenwerkingsafspraken sectorstandaarden voor de corporatiesector. Around thirty parties that deliver software, IT services or IT support to corporations using one or more sector standards had signed it as of July 2026. Signing commits a supplier to working with Aedes on developing and implementing the standards on that roadmap.
Read the scope again and the gap is obvious. The covenant is for parties that help develop and implement a sector standard. An AI supplier building a retrieval assistant over your policy documents, or a model that scores arrears risk, consumes data that these standards govern but develops and implements none of them, which is what a signatory commits to. It sits outside the covenant by design rather than by neglect. We are not a signatory either, and no AI-specific standard appears on the roadmap. What follows is the procurement-side substitute, not a complaint about the covenant.
Someone made the collective version of this argument first, and it deserves naming. In January 2023 the AI Hub Woningcorporaties (with Staedion, Portaal, Trivire, WonenBreburg, Mooiland and Thuisvester as premium members) proposed developing sector models together with reference to standards such as VERA, arguing that commercial vendors sell the same model separately to each corporation and often lack the domain knowledge. The collective route has since reappeared through a different vehicle. In July 2026 Aedes published three AI solutions from de Alliantie as open source: the Ally chatbot, an internal ChatGPT variant with a minutes generator for VvE meetings, and the Verhuiskans algorithm that predicts where moves will happen and is described as supporting fairer allocation, all three through the Aedes open-source GitHub. Woonstad Rotterdam has published a VERA test framework there that checks whether data follows the standard, using PySpark. That is the argument of this post, already running in code. None of it changes what you need when you buy from a commercial supplier, which is where the contract is the only lever you hold.
Which of the five standards does an AI project actually touch?
Aedes itself told the sector how to start with AI safely and responsibly in July 2026, and that guidance covers the AI Act risk tiers and the provider-versus-deployer split. It says nothing about which sector standard an AI system touches. That mapping is what nobody writes down, and it is a twenty-minute conversation that saves a quarter. Work it out per data flow, not per project.
Any system reading tenant, unit or allocation data touches VERA; this is most of what gets built, from arrears prediction to a tenant-contact assistant. Predictive maintenance and condition scoring touch ILS-woco, because the real estate information is the feature set. Invoice, cost and budget automation touches RGS-woco, and the general ledger scheme is what makes the output comparable to anything else you report. Work-order automation involving maintenance firms touches DICO-woco, because the message is the integration. And anything in the allocation funnel that reads or re-uses an applicant's income data touches DIV-it, which governs how the digital income statement is obtained and handled for the mandatory income check.
Write that column next to each use case in your AI backlog before the first supplier meeting. A supplier who asks which of the five apply is a supplier who has read the sector. One who has never heard of them is not disqualified, but you now know which translation work is yours.
What did the sector already learn from fifteen connections?
The corporation sector has paid for this lesson once, in Dutch, with its own money. Before VERA standardised housing allocation, an ERP supplier maintained a separate connection to every woonruimteverdeler, sometimes fifteen at once, as Arjen de Vries described it in CorporatieGids Magazine in December 2019. Standardisation collapsed that to one connection with a consistent interpretation of the data, and the same account reported that the then-new VERA version reached full coverage of the dVi.
That history has a direct consequence for AI procurement. An AI supplier who opens with “just send us a CSV export of tenants and units” is proposing connection sixteen: a private vocabulary, mapped once, in a script only they can read, going stale the week after go-live. The sector's answer to that pattern already exists; the AI project is simply the newest place it shows up. Our own argument about integrating AI with legacy ERP without replacing it applies here, with the sector model doing the work the integration layer usually has to invent.
One caveat, because it matters for how you use this. This is a Netherlands story. CORA, VERA and the Aedes covenant govern Dutch corporations; Flemish social housing sits under different bodies and different standards, and none of the above transfers to a Flemish woonmaatschappij, the form Flemish social housing bodies have taken since 1 July 2023.
Is an AI ranking in woonruimteverdeling a high-risk system?
Possibly, and this is the question to resolve before the pilot rather than after it. The European Commission's own AI Act Service Desk lists, as a high-risk example under Annex III point 5(a), evaluation of the eligibility of a natural person for essential public assistance benefits and services, an AI system intended to evaluate applications for social housing by prioritising applicants on eligibility and urgency. That is a recognisable description of a ranking layer on a woonruimteverdeling system.
The honest complication is whether the provision reaches you, and the category is not where the doubt sits. Annex III point 5(a) covers AI systems intended to be used by public authorities or on behalf of public authorities, so a private body acting for one is plainly inside the wording. The open question is narrower: whether a toegelaten instelling, a private foundation with a statutory task, is acting on behalf of a public authority when it allocates, and whether allocation is an essential public assistance service. The Service Desk's examples assume a public administration and never reach that case. Do not treat the gap as an exemption you have found. Get it decided, in writing, by whoever advises you on the Woningwet, and keep the decision with the system.
Timing gives you room, not comfort. Regulation (EU) 2026/1744, the Digital Omnibus on AI, entered into force on 27 July 2026 and moved the obligations for stand-alone Annex III systems to 2 December 2027, with product-embedded Annex I systems following on 2 August 2028. That is one procurement cycle away for a system you are scoping now. Our AI Act risk checker walks the classification.
What do you require instead of covenant membership?
Five clauses. They are deliberately boring, which is the point: each one survives a change of supplier.
First, read from the standard, not from an export: the supplier reads through VERA-conformant interfaces where they exist, and where they do not, the mapping from your source fields to VERA entities is a written deliverable that you own. Second, name the standards in scope per data flow, using the mapping above, in the statement of work rather than in a kickoff slide. Third, make reportable figures reproducible: if anything the system computes reaches your dVi or dPi, the supplier owes you the model version, prompt version and index snapshot that produced the number, because the accountability chain for that figure ends with you and the Autoriteit woningcorporaties, not with them.
Fourth, place it on your architecture: the supplier states which CORA business function and which application component the system is. If they cannot place it, your architect will have to later, and that conversation is cheaper before the build. Fifth, define exit in sector terms: on termination you keep the field mapping, the evaluation set and the prompt and model registry, not an API key and a goodwill clause. Whoever holds the mapping and the evaluation set can change supplier; whoever does not, cannot, which is the line we drew in the AI capability you should not outsource.
Where does this leave your ICT partner, and us?
Your ICT partner runs the estate: infrastructure, identity, the service desk, the change calendar. We do not, and will not claim to. Crux Digits is the AI partner that works alongside your ICT partner; we do not sell beheer, infra, helpdesk or 24/7 support, and a corporation that bought AI from a party promising all of it has bought a dependency rather than a capability. Practically, the line falls like this: the ICT partner owns the connection and the identity, the AI supplier owns the model, the mapping and the evaluation set, and you own the architecture decision and the standards register.
Two earlier pieces finish the thought. Who gets paged when the AI breaks covers the gap between two SLAs that never reference each other, which in a corporation lands on a service desk with no category for “the answer was wrong”. The AI RACI is the matrix we draw with your IT organisation and your ICT partner before anyone writes code.
Before your next IT steering meeting, do three things. Put the five-standard column next to every item in your AI backlog. Ask your prospective supplier which of the five their system touches and listen to the shape of the answer. And settle the Annex III question for anything near woonruimteverdeling now, while the scope is still a document. If you want a hand with the mapping, that is the kind of work we do for mid-sized organisations and the broader approach is on our AI implementation in the Netherlands page.
We build custom AI and LLM systems that run in production: a clickable MVP by the second call, fixed steps, and you own the code.
AI development agency in the Netherlands →
