Een praktische ontwerpkeuze is om de communicatie met een externe AI-dienst op één herkenbare plek onder te brengen. Daar wordt geregeld hoe gegevens worden verstuurd en hoe antwoorden worden terugvertaald naar de toepassing.
De bedrijfsregels blijven in de eigen software. Denk aan de voorwaarden waaronder een aanvraag mag worden goedgekeurd of welke gegevens verplicht zijn. Zo voorkom je dat zulke regels verspreid raken over verschillende leverancierskoppelingen.
Deze scheiding kan wijzigingen overzichtelijker maken, maar vraagt zelf ook onderhoud. Leg daarom vast welke gegevens de koppeling verwacht, hoe fouten worden afgehandeld en wie het onderdeel beheert.
Een voorbeeld: laat de AI een categorie voorstellen voor een binnenkomende aanvraag. De applicatie controleert vervolgens of die categorie bestaat en welke vervolgstap daarbij hoort. Daardoor blijft duidelijk welk onderdeel verantwoordelijk is voor welke beslissing.
Regel wat er bij uitval gebeurt
Geef je software een bruikbare terugvaloptie.
Bepaal vooraf wat een gebruiker moet kunnen doen wanneer de AI-dienst niet reageert. Kan een opdracht wachten, moet een medewerker deze overnemen of moet alleen de betreffende functie tijdelijk stoppen?
Denk aan een toepassing die documenten automatisch beoordeelt. Bij een storing kun je documenten als ‘wacht op verwerking’ bewaren en medewerkers de mogelijkheid geven ze handmatig te behandelen. Maak daarbij duidelijk welke opdrachten nog openstaan.
Voorkom ook dat de software een langdurig onbereikbare dienst blijft aanroepen. Bouw een grens in waarna nieuwe pogingen tijdelijk worden gepauzeerd. Daarmee beperk je onnodige belasting.
Test vervolgens het herstel. Wat gebeurt er met wachtende opdrachten wanneer de dienst terugkomt? En hoe voorkom je dat handmatig afgehandeld werk alsnog automatisch wordt uitgevoerd? Met zulke scenario’s maak je de terugvaloptie onderdeel van de werkende software.