Bus factor: when only one person knows the self-built AI

What is the bus factor?

The bus factor is the smallest number of people whose absence leaves a system without anyone able to maintain it. If it is one, everything depends on a single person. That is no criticism of this person: usually it is the one who first took an interest in AI, set up a server and helped colleagues. The risk arises when this commitment turns into a service for many people without the maintenance being shared as well.

Why is the bus factor of self-built AI often low?

An AI system in your own organisation consists of many layers: operating system, drivers for the GPUs, containers, the software that runs the model, the model itself, an interface, a database, sign-in and connections to specialist systems. Each layer has its own versions and settings. How they fit together is often known only to the person who set them up, plus a few notes.

Then there is the pace: models and software are released at short intervals. Anyone who does not keep up continuously soon loses track, and a stand-in can hardly be trained up to cover two weeks of holiday.

Does this also apply to the open source projects themselves?

Yes, to a lesser extent. A 2016 study estimated the bus factor of 133 well-known projects on GitHub: for 65% it was two at most. That says nothing about any single project today, but it shows that widely used software can also depend on a few people. For the components you rely on, check: how many people contribute regularly? Is there a company or foundation behind it? How quickly are security vulnerabilities fixed?

What do regulations require?

Among the obligations for entities in scope, the NIS2 Directive lists business continuity (Art. 21(2)(c)) and human resources security (point (i)). The German Federal Office for Information Security (BSI) covers staff changes and deputies in IT-Grundschutz (module ORP.2 Personnel) and emergency preparedness in BSI Standard 200-4. An AI system that many people rely on belongs in this planning like other important applications. More on this in the guide on emergency operation if the AI platform fails.

What raises the bus factor?

• A second person: at least one more person who can handle updates, restores and faults independently, and does so regularly.
• Installation by script: the environment can be rebuilt from versioned files instead of being set up by hand.
• Operations manual: architecture, access, versions, dependencies, procedures for updates and restores, contacts.
• Practised restore: a backup only counts once someone else has restored it at least once.
• Maintenance contract: a service provider who knows the environment and takes over in an outage, with a data processing agreement if it has access to data.
• Less custom building: every self-written connection and every special solution is knowledge that someone has to keep.

And with a purchased platform?

The bus factor shifts to the provider. So ask: who provides support, and at what times? Can you get your data, knowledge collections and settings out? What happens to the software if the provider ceases to exist, for example through escrow of the source code or its publication? See the guide Exit strategy and data portability.

How does this work with basebox?

Updates, new models and support are included in the licence; support is available on working days from 9 am to 5 pm. On request, we operate your server remotely. Apps with their instructions, knowledge bases and settings can be exported. If basebox becomes insolvent, the code will be published as open source so that customers can keep working; with the server, basebox runs on your hardware.