The proof: ask the AI itself
Try asking a chatbot for a month’s roster for thirty nurses across three shifts, with your unit’s constraints. If it answers with a table written on the spot, check it: you will find an afternoon→morning sequence with less than 11 hours of rest, an uncovered night shift, a part-timer over their hours. That is not a defect of that particular product: a text generator produces probable text, not certified solutions. But today’s assistants, when they can run code, do the most sensible thing: they model the problem and hand it to an optimization solver. Even generative AI, for rosters, calls an engine. And that is where the test gets interesting, because it opens the real questions: which engine did it use and who stands behind it; where did names, absences and restrictions end up; who updates the rules next month, when the local agreement changes or a new fitness-for-work restriction arrives; who is accountable for a violated constraint; how does the plan reach time and attendance, the staff portal and the app. A successful experiment is not a system.
Hard and soft constraints: the difference that is unforgiving
Anyone who plans rosters knows it: constraints are not all alike.
- Hard constraints can never be broken: the 11-hour rest period, minimum coverage per time band and skill, one shift per day, forbidden sequences. A plan that violates even one of them cannot be approved: if staffing is short, the gap must be seen and decided, not hidden.
- Soft constraints can be violated, but at a price: shift preferences, fair distribution of nights and public holidays, sustainable sequences. Every violation carries a cost, and the best plan is the one that costs the least.
An optimization engine treats the former as inviolable rules and the latter as penalties to minimize, with adjustable weights. A text generator does not distinguish between the two: to it, “almost satisfied” and “satisfied” look alike. On a ward, they don’t.
Why “plausible” is not enough in healthcare
The Nurse Rostering Problem has been studied for decades by operations research because it is combinatorially explosive: every additional person and rule multiplies the cases. Nobody — planner or chatbot — can verify every rest period and every average over a month “by eye”. That is why correctness must be sought by the method and verified constraint by constraint before approval — not checked by eye, hoping to catch everything.
Where the data goes
To build a roster you need names, absences, restrictions, fitness for work: personal data, often health data. With a consumer chatbot account, conversations are retained by default and may be used to train models, with no data-processor agreement: for the staff of a healthcare organization that is the wrong contract, not the wrong tool. Business plans and APIs exclude training, but data location, transfers outside the European Union and the impact assessment still need checking. In ALISEO ES the data never leaves the platform: the engine optimizes inside your organization’s tenancy, in the ACN-qualified SaaS (listing SA-4199), with no calls to external models and no training on your data. Even when the model runs in the regional or in-house data centre, the question moves but does not disappear: who provides and maintains the constraint engine, who approves the plan, how it reaches time and attendance and the people who work the shifts. A documented engine and a “sovereign” language model are not alternatives: one guarantees the plan, the other helps to request and explain it. The question for every vendor, ourselves included: when the roster is generated, where does the staff data go, who processes it, and under which contract?
Two routes, one solver
Anyone who wants to “put AI” into a rostering system faces two routes. They start from the same point: the system, with its archive of hard and soft constraints, the roster boards, the staff, the pre-assignments, the restrictions. And they end at the same point: shifts on the roster board, the coordinator’s checks, approval. What changes is what sits in between.
On the first route a language model sits in between: it builds a prompt from the system’s data and constraints, picks a solver and asks for the roster. But it must have a solver. Frontier models do, and at every run the data leave the system and tokens are consumed. A “sovereign” model in the regional data centre does not, until an expert loads or builds one.
On the second route the solver is already in the product: it reads the constraints from the archive, with the weights set in the system, and returns the shifts on the roster board without a single record leaving. With or without AI, you always need a solver: what changes is who provides it, where it runs and who maintains the constraints.
The right tools exist (and you can read about them)
Operations research offers mature families of methods: constraint programming, integer linear programming, metaheuristics. ALISEO ES uses Simulated Annealing, in the version born from research with the University of Udine, published in a peer-reviewed journal and tested on the benchmarks of the international INRC competitions: the engine searches, within a set time, for the best solution within the configured hard constraints, distributing the soft ones fairly — building it around the requests already entered (preferred shifts, leave, statutory leave), never against them. The plan is always approved by the coordinator after the pre-approval checks: while a blocking anomaly remains, rest periods, coverage, care levels, the plan does not move forward; mid-month exceptions are allowed and logged. Every proposal made by the engine is logged: for the information owed to workers under Italian transparency and AI legislation, the logic, parameters and control measures are available to the organization. We explain how it works here: Optimizing rosters with operations research: what Simulated Annealing is.
The question to ask every vendor
Generative AI is an extraordinary tool — for writing, summarizing, assisting. And the ALISEO ES engine is artificial intelligence too: from the right family for this problem. The difference that matters is not the “AI” label on the brochure, but verifiability: which algorithm? is it documented? can the plan be checked constraint by constraint? who approves it? and where does the data go? If the answer is “proprietary algorithms” and nothing else, you are buying a promise. Documented, verifiable AI can be recognized by one simple thing: the method is published and the plan can be checked constraint by constraint. You can read it.
→ Read more: Shift optimization