Verantwoorde AI, Veiligheid & Risico voor Architecten — Claude Certified Architect Professional Prep Course

Screen 1: De veiligheidsstapel: wie is eigenaar van elke laag, en wat gebeurt er als er een faalt

ORIËNTATIE MODULE 2 MIN De veiligheidsstapel: wie is eigenaar van elke laag, en wat gebeurt er als er een faalt

De eerdere modules eindigden met een operationeel productiesysteem: elke stap van een partnervraagstuk was aan de juiste eigenaar toegewezen, een referentiearchitectuur en een model waren gekozen, het use case was gedimensioneerd, evals waren gebouwd als acceptatiecriteria, en de integratielagen waren ingesteld om Claude in een enterprise-stack in te bedden.

Deze module behandelt de grote veiligheidsvraag: welke controles zijn er ingesteld om te voorkomen dat een systeem een geldige aanvraag weigert, een oneerlijk resultaat oplevert, of een actie onderneemt die niemand heeft goedgekeurd? Veiligheid is een volledige set controles, elk bedekt een ander deel van het aanvraagpad, elk met een blinde vlek die de volgende moet opvangen. De Architect is verantwoordelijk voor het plaatsen van elke controle en het bepalen wat te doen als deze faalt.

Aan het einde van deze module kunt u: 1 Onderscheid maken tussen wat de training van het model reduceert en wat uw applicatielaag nog moet afdwingen. 2 Input screening, output screening en tool-call autorisatie op de juiste punten in het aanvraagpad plaatsen en bepalen wanneer u model-gebaseerde versus deterministische controles moet gebruiken, zodat het systeem gesloten faalt in plaats van open. 3 Identificeren waar ongelijke resultaten in een systeem kunnen ontstaan en de verklaringen definiëren die vereist zijn voor gebruikers, regelgevers en uw eigen debugteam, zodat eerlijkheid en transparantie in het ontwerp zijn ingebouwd. 4 Beslissingen naar de juiste reviewer/besluitvormer routeren op basis van vertrouwen, reversibiliteit en de kosten van een fout antwoord, zodat reviewinspanning gericht is op de beslissingen die erom vragen. 5 Elke nalevingsverplichting toewijzen aan een benoemde controle, een eigenaar en een bewijsartefact, zodat de architectuur nauwkeurig kan worden gecontroleerd.

Deze module is voor de Architect die al een werkend systeem heeft gebouwd: eigenaarschap toegewezen, architectuur gekozen, evals gebouwd en Claude in een enterprise-stack ingebouwd. Claude komt met breed veiligheidsgedrag, maar kent niet de gegevensafhandelingsregels, autorisatiemodel of domeinbeleid van de partner. Aannemen dat Claude een regel afdwingt die het nooit heeft gekregen, is de meest voorkomende manier waarop een veiligheidsontwerp kan mislukken.

Alles in deze module is gebouwd rond één context: een systeem dat elke architectuurreview doorstaat en toch in productie faalt. De verantwoordingslaag was onvolledig, aangenomen of correct op ontwerptijd maar fout op het moment dat iemand het controleerde. De partners zijn enterprise-kopers in gereglementeerde omgevingen, waar een controle die in een demo solide lijkt, een auditbevinding wordt wanneer configuraties afwijken of een reviewer om bewijs vraagt dat de controle actief is.

DE BESLISSINGEN KAARTEN AF OP DE SECTIES HIERONDER

De uitlijninggrens is waar u de lijn trekt tussen wat de training van het model al reduceert en wat uw applicatielaag nog moet afdwingen. Aannemen dat getrainde uitlijning een domeinbeleid dekt, laat de regel in elke laag onafdwingbaar. De module begint hier omdat dit elke verdere beslissing beïnvloedt.

Guardrail-plaatsing is waar u input screening, output screening en tool-call autorisatie op het aanvraagpad positioneert, kiest of elke controle model-gebaseerd of deterministisch is, en bepaalt wat de controle doet als deze faalt. Een enkel filter aan het einde van het pad dekt de andere twee punten niet, en een controle die open faalt is erger dan geen controle, omdat het de schijn van bescherming geeft zonder enige functie.

Eerlijkheid en transparantie is waar u identificeert waar ongelijke resultaten het systeem kunnen binnenkomen, en ze bouwen de logging die u in staat stelt elke beslissing achteraf uit te leggen. De vier injectie-punten zijn van u om te instrumenteren.

Human-review routing is waar u bepaalt welke beslissingen een persoon moet wegen en wat die reviewer nodig heeft om hun werk te doen. Eenvoudig routeren op volume overspoelt de wachtrij en dwingt reviews vaak in te storten tot goedkeuringen. De beslissingen die aandacht verdienen, zijn die met hoge inzet en laag vertrouwen, en die inzet moet vooraf worden geïdentificeerd.

Het nalevingscontrolerregister is waar elke verplichting een geïdentificeerde controle, een verantwoordelijke eigenaar en een bewijsartefact wordt die een reviewer kan inspecteren. Het kiezen van een nalevingsingang is een vereiste. Een controle zonder eigenaar en zonder levend artefact kan niet-operationeel gaan zonder dat iemand het opmerkt, en verschijnt dan als een gat tijdens een audit.

Deze onderwerpen bouwen op elkaar voort. De grens die u in de eerste sectie trekt, wordt afgedwongen door de controles in de tweede, de logging die u voor eerlijkheid bouwt, is dezelfde logging die de reviewer in de vierde sectie gebruikt, en het controleregister in de vijfde sectie trekt op elke geinstrumenteerde laag hierboven. De cumulatieve taak aan het einde vraagt u alle vijf in een verdedigbare implementatie uit één briefing samen te stellen, wat precies wat deze module u voorbereidt om voor een veiligheidsreviewer of nalevingsauditor te doen.

DISCLAIMER / KENNISGEVING VOOR EDUCATIEVE INHOUD

We hebben deze Architect-cursus Module 3: Verantwoorde AI, Veiligheid en Risico voor Architecten gebouwd om u echt werk met Claude te helpen doen. Behandel het als educatieve inhoud. Het vormt geen juridisch, financieel of ander professioneel advies, dus pas wat u leert aan uw eigen situatie aan. Onze producten en services evolueren snel, dus bepaalde inhoud kan fouten bevatten of verouderd zijn; vergeet niet om op de website of docs van Anthropic te verifiëren. Voorbeelden en scenario's die in de cursus worden gebruikt, zijn illustratief en vaak fictief. Als de cursusmateriaal een bedrijf of product noemt, betekent dit niet dat Anthropic het aanbeveelt, zij Anthropic aanbevelen, of dat we ermee verbonden zijn. Houd er ook rekening mee dat uw gebruik van Anthropic-producten en -services wordt beheerst door onze voorwaarden, beleid en documentatie; als iets in deze cursus hiermee in conflict is, hebben zij voorrang.

Screen 2: Wat de training van het model afdwingt versus wat u bezit

TeachingAlignment11 min Wat de training van het model afdwingt versus wat u bezit Eerder werk stelde de architectuur, het model en de integratie vast. Hier beantwoorden we: voordat u begint met het toevoegen van controles, hoeveel veilig gedrag wordt al door het model afgehandeld, en hoeveel is nog van u om te bouwen? U moet deze grens duidelijk begrijpen om te voorkomen dat u dubbele beschermingen maakt of aanneemt dat het model een regel afdwingt die het nooit heeft gezien.

Anthropic traint Claude tegen een grondwet: een geschreven document dat de waarden en het gedrag beschrijft die het model moet vertonen, zodat het model met breed veiligheidsgedrag al ingesteld wordt. Anthropic herziet dit document in de loop van de tijd, en de meest recente gepubliceerde versie is van januari 2026. Het document wordt tijdens training gebruikt om voorbeelden te genereren die het model van leert en om kandidaatresponsen in te rangschikken. Dit vormt hoe het model reageert op ambigue of gevoelige aanvragen, maar vangt niet noodzakelijk slechte outputs. Het stelt een prioriteitsvolgorde in die het model moet volgen wanneer doelen conflicteren: wees breed veilig, wees ethisch, voldoe aan richtlijnen en wees echt behulpzaam voor operators en gebruikers. Die volgorde is belangrijk omdat een behulpzaam antwoord soms onveilig is. De volgorde is holistisch in plaats van strikt, dus doelen met hogere prioriteit hebben over het algemeen voorrang wanneer ze conflicteren, hoewel het model ze samen weegt in plaats van ze in een starre volgorde toe te passen. Het model komt met een klasse schadelijke output al gereduceerd voordat u een enkele prompt schrijft. De ingebouwde laag behandelt breed, algemeen schadelijk, maar dekt uw specifieke domein niet: alle beleidsregels specifiek voor uw gebruikers en product zijn nog van u om af te dwingen.

Training-time alignment en inference-time control zijn twee lagen met verschillende doeleinden Training-time alignment vormt modelgedrag vóór implementatie. Het reduceert brede klassen schadelijke output door Claude te sturen om gevaarlijke aanvragen te weigeren en naar veiliger reacties te neigen. Omdat het vóór enige implementatie wordt ingesteld, is het van nature algemeen. Dit is zowel een sterkte als een zwakte: het kent uw partnerdomeinbeleid, gegevensafhandelingsregels of autorisatiemodel niet. Een aanvraag kan passen in Claudes algemene uitlijning en toch een implementatie-specifieke regel schenden, zoals het openbaren van orderinformatie van een ander klant of advies buiten een goedgekeurd script. Onthoud, Claude kan geen regel afdwingen die het nooit heeft gekregen. Implementatie-specifieke regels worden afgedwongen door de tweede laag: inference-time control. Dit omvat de runtime guardrails die u voor uw implementatie configureert, zoals systeeminstructies, input- en outputcontroles, toolmachtigingen en human review gates. Systeeminstructies vormen het gedrag van het model, maar implementatie-specifiek beleid wordt alleen afgedwongen wanneer die instructies zijn gekoppeld aan runtime-controles zoals screening, autorisatie en review. Training-time alignment verlaagt het basisrisico, en inference-time control dwingt de regels specifiek voor uw implementatie af.

Een gelaagde weergave: elke laag heeft een taak en een blinde vlek Behandel veiligheid als vier lagen gestapeld van Claude naar buiten. Elk dekt iets wat de laag eronder niet kan, en elk faalt op een manier die de volgende moet opvangen. Selecteer elke laag om te zien wat het betrouwbaar dekt, wat niet, en wie het bezit.

Getraind gedrag Systeemprompinstructie Runtime screening Autorisatie

Wat het betrouwbaar dekt: Brede klassen schadelijke of onveilige output, toegepast op elke aanvraag zonder configuratie. Wat het niet dekt: Uw domeinbeleid, uw gegevensregels, uw autorisatiemodel. Wie het bezit: Anthropic.

Wat het betrouwbaar dekt: Rol, toon en gestelde beperkingen die Claude in één aanvraag sturen. Wat het niet dekt: Alles wat een adversarische of ongebruikelijke input Claude uit kan praten, omdat instructies geen afdwinging zijn. Wie het bezit: Architect.

Wat het betrouwbaar dekt: Input- en outputscreening die niet-toegestane inhoud detecteert. Wat het niet dekt: Acties met bijwerkingen, die screening niet autoriseert, en nieuwe aanvallen die een classifier mist. Wie het bezit: Architect.

Wat het betrouwbaar dekt: Of een specifieke actie met bijwerking voor deze beller in deze context is toegestaan. Wat het niet dekt: Inhoudskwaliteit en eerlijkheid. Wie het bezit: Architect.

Kosten · Complexiteit · Risico Kosten: Elke toegevoegde laag kost latentie en engineering. Een pre-screen op input en een controle op output voegen twee extra oproepen of regels toe aan elke aanvraag. Complexiteit: Vier lagen betekent vier plaatsen om te ontwerpen, versie en testen. De systeemprompt en de screeninglogica drijven onafhankelijk af als ze niet worden beheerst. Risico: De gevaarlijkste fout is een stille: aannemen dat Claude een domeinregel afdwingt die het nooit heeft gekregen. Omdat de regel in geen enkele laag bestaat, voorkomt niets een schending.

Screen 3: Wanneer getrainde weigering wordt verward met een domeinbeleid

Watch OutAlignment3 min Wanneer getrainde weigering wordt verward met een domeinbeleid

Setup hook U bent een sterke systeemarchitect. Claude weigert al breed schadelijke aanvragen in testen, dus u neemt aan dat de training ook het gegevensafhandelingsbeleid van uw partner dekt. U gaat verder zonder een aparte afdwingingslaag te bouwen.

Een postmortem: een beleid dat nooit in enige laag is gecodeerd Een team implementeerde een interne assistent voor een partner waarvan het gegevensafhandelingsbeleid gebruikers verbood records van andere bedrijfsonderdelen te openen. Bij review had Claude elke schadelijke prompt die het team ertegenaan gooide geweigerd, dus ze gingen ervan uit dat cross-unit openbaring door hetzelfde veiligheidsgedrag werd gedekt en bouwden nooit een autorisatiecontrole ervoor. In productie vroeg een normaal uitziende, in-domain aanvraag om een verboden record. Niets in de aanvraag zag er in algemene termen schadelijk uit, dus Claude beantwoordde het. De regel die het team dacht af te dwingen bestond eigenlijk niet. Het was nooit onderdeel van Claudes training, en het team codeerde het nooit in een classifier, systeemprompt of applicatiecontrole, omdat ze aannamen dat het model het al dekte.

Waarom dit faalde Een domeinbeleid werd verward met getrainde uitlijning. Getrainde weigering dekt breed schadelijk, niet implementatie-specifieke regels. Elke regel die specifiek voor uw partner is, moet in een laag die u bouwt, worden afgedwongen. Onthoud, Claude kan niet afdwingen wat het nooit heeft gekregen.

Screen 4: Sorteer de verantwoordelijkheid

CheckpointAlignment3 min Sorteer de verantwoordelijkheid Probeer het nu. U beoordeelt het veiligheidsontwerp voor een Claudeassistent van een partner. Sleep elke verplichting in de bak die deze moet afdwingen: ofwel Claudes getrainde gedrag, ofwel de applicatielaag. De feedback legt uit waarom elk ergens valt.

Weigering om te helpen een gevaarlijk wapen te synthetiseren Nooit de gegevens van een ander huurder teruggeven Weigering om duidelijk haatdragend inhoud te produceren Advies buiten het goedgekeurde script van de partner blokkeren Handtekening vereisen voordat een terugbetaling wordt uitgegeven

Claudes getrainde gedrag

Applicatielaag (u bezit het)

Controleer antwoorden Sla over voor nu

Screen 5: Risico's, beperkingen en foutmodi van LLM-systemen

TeachingGuardrails9 min Risico's, beperkingen en foutmodi van LLM-systemen U hebt de controles geplaatst; identificeer nu wat ze verdedigen. Van een Architect wordt verwacht dat hij een risicobeoordeling voor een voorgesteld systeem uitvoert en documenteert als onderdeel van een veiligheidsleverantie. Dit scherm behandelt de risicocategorieën die in LLM-systemen terugkeren en zet ze om in een geschreven beoordeling die u kunt uitvoeren.

De risicocategorieën die in LLM-systemen terugkeren Het meeste LLM-systeemrisico valt in een kleine set categorieën. Identificeer deze categorieën en controleer uw ontwerpen tegen elk:

Direct prompt injection: Een gebruiker stelt input op die de instructies van het systeem overschrijft en het gedrag omleidt. Indirect prompt injection: Schadelijke instructies arriveren via opgehaalde inhoud of tooloutputs die het model als vertrouwd behandelt en die de vector-inputscreening niet vangt. Token-budget uitputting: Oversized of adversariaal gevoerde inputs verbruiken de context- of outputbudget, trunceren werk of verhogen kosten. Tool- en actiemisbruik: Het model wordt ertoe gebracht een side-effecting tool buiten beleid aan te roepen, de fout die de action-autorisatiecontrole moet stoppen. Gegevensblootstelling: Gevoelige velden voeren de context window of de logs in waar ze niet horen, waardoor een lek ontstaat onafhankelijk van modelgedrag.

Systeemkwetsbaarheidsanalyse: waar te kijken Loop de aanvraag- en gegevenspaden samen. Bij elk ingang, gebruikersinvoer, opgehaalde inhoud, tooloutputs, de eigen output van het model en de logs, vraag wat een tegenstander zou kunnen doen en welke controle in de weg staat. Zoek naar overal zonder controle waar een plausibele aanval zou kunnen zijn.

De risicobeoordeling als leverantie documenteren De risicobeoordeling moet een geschreven artefact zijn. Voor elk geïdentificeerd risico, noteer de categorie, de betreffende component, een waarschijnlijkheids- en impactbeoordeling, en de mitigatie-controle met een eigenaar en een bewijsartefact. Dat document is wat de veiligheidsreviewer zal ondertekenen, en het is wat de cumulatieve oefening aan het einde van deze module van u verwacht te kunnen produceren.

Screen 6: Beoordeel de risico's in een voorgestelde architectuur

CheckpointGuardrails4 min Beoordeel de risico's in een voorgestelde architectuur Probeer het nu. U beoordeelt een voorgestelde architectuur: een klantenserviceagent die antwoorden uit een partnerkennisbank ophaalt en terugbetalingen via een verbonden tool uitgeeft, met alle activiteiten geschreven naar een aanvraaglog. Identificeer minstens drie risicocategorieën in dit ontwerp, en noem voor elk een werkbare mitigatie. Zowel het risico als een mitigatie die het aanpakt, zijn vereist.

Identificeer de risicocategorieën in dit ontwerp en koppel elk aan een mitigatie.

Onthul modelantwoord Sla over voor nu

Modelantwoord

Indirect prompt injection via de kennisbank. Opgehaalde inhoud kan instructies dragen; mitigatie is opgehaalde tekst als niet-vertrouwd behandelen en tool-/inhoudsinvoer screenen, niet alleen gebruikersinvoer.
Tool- en actiemisbruik op het terugbetalingstool. Mitigatie is een action-autorisatiecontrole die vóór de terugbetalingstool wordt uitgevoerd, onafhankelijk van de modeloutput.
Token-budget uitputting op grote kennisbankdocumenten. Mitigatie is chunking en invoerlimieten plus budgetbewaking zodat een groot document het werk niet stilzwijgend trunceert.
Gegevensblootstelling in het aanvraaglog. Mitigatie is server-side redactie van gevoelige velden voordat iets wordt geregistreerd.

Screen 7: Screening en autorisatie plaatsen zodat het systeem veilig degradeert

TeachingGuardrails14 min Screening en autorisatie plaatsen zodat het systeem veilig degradeert Een controle die aanvragen screent, kan op dezelfde manier falen als elke afhankelijkheid faalt. Het kan time-out, een fout retourneren of onbereikbaar worden onder belasting. Het verschil is dat een falende guardrail er nog gezond uit kan zien: wanneer een screeningservice een fout maakt maar nog steeds verkeer doorgeeft, blijven aanvragen stromen terwijl de controle geen van het werk doet waarvoor het er was. Dus, wanneer een guardrail een fout maakt, moet het systeem één van twee dingen doen: het doorlaten of blokkeren. Als u die keuze niet expliciet hebt gemaakt, beslist de omringende code voor u. De standaard is bijna altijd om het aanvraag door te laten, wat betekent dat u terugvalt op het onbeschermde pad. Dezelfde redenering die retries en circuit breakers rond uw modeloproepen plaatste, is hier van toepassing: bepaal hoe de controle zich gedraagt wanneer het faalt, in plaats van het gedrag over te nemen dat toevallig aanvragen laat stromen.

Waar guardrails in een aanvraagpad zitten Een beveiligd aanvraagpad heeft een paar besluitpunten, elk beantwoordt een ander vraag.

Input screening loopt vóór de modeloproep en beslist of de aanvraag het model helemaal moet bereiken. Output screening loopt vóór de reactie de gebruiker bereikt en beslist of wat het model produceerde veilig is om terug te geven. Tool-call autorisatie loopt vóór enige actie met bijwerkingen, zoals het verzenden van een e-mail, schrijven naar een database of het uitgeven van een terugbetaling, en bepaalt of deze beller deze actie in deze context mag uitvoeren.

Omdat ze op verschillende plaatsen zitten en verschillende dingen controleren, doet een controle op één plaats niets voor de anderen, daarom kan een enkel filter het hele pad niet dekken.

Waar elke controle past: model-gebaseerd versus deterministisch per besluitpunt Besluitpunt Een model-gebaseerde controle is nodig wanneer Een deterministische controle is beter wanneer

Input screening (vóór de modeloproep) Intentie is ambigu en u vangt jailbreak- of prompt-injectiepatronen die niet uitputtend met regels kunnen worden vastgelegd. Een lichtgewicht model classificeert de invoer. De regel is duidelijk en gedefinieerd: een blocklist, een regex, een lengte- of formaatcontrole. Het is sneller, voorspelbaar en kan niet uit zijn beslissing worden gepraat. Output screening (vóór de reactie de gebruiker bereikt) U evalueert kwaliteiten zoals toxiciteit of nalevingsbeleid die taalkennis nodig hebben. Een judge model scoort de output. U controleert op een bekende string, een verboden veld of een schemaschending die een validator met zekerheid vangt. Tool-call autorisatie (vóór enige side-effecting actie) Zelden. Autorisatie moet deterministisch zijn, zodat het controleerbaar is. Bijna altijd: een allowlist van toegestane acties, identiteitscontroles en scopevalidatie. Autorisatie moet een beslissing zijn die u kunt bewijzen en opnieuw afspelen, dus het moet deterministisch zijn.

Waarom model-gebaseerde en deterministische controles anders falen, en waarom u ze ketent Een model-gebaseerde classifier kan worden omzeild: een gebruiker kan een invoer op een manier formuleren die zelfs de sterkste judge model omzeilt. Een deterministische regel is broos: het blokkeert precies wat het is geprogrammeerd om te detecteren en niets meer. Het mist alles wat het niet voorzag en over-blokkeert alles wat op een beperkt patroon lijkt. Er is geen controle die alles vangt, dus deze controles worden in serie ingezet. Identificeren wat elk mist, zorgt ervoor dat elke gat opzettelijk door een ander controle wordt gedekt in plaats van open te blijven.

Een tweede injectievector: instructies die via opgehaalde inhoud en tooloutputs arriveren Gebruikersinputscreening vangt instructies die de gebruiker rechtstreeks verzendt. Het vangt geen instructies die in inhoud zijn ingebed die het systeem ophaalt of van tools ontvangt. In een RAG-systeem bereikt een schadelijke instructie in een opgehaald document het model nadat inputscreening de aanvraag al heeft doorgelaten. In een agentic systeem kan een toolreactie instructies dragen die het model als gezaghebbend behandelt. Dit is de dominante injectievector in enterprise-implementaties met retrieval of toolgebruik, en het vereist een aparte controle: opgehaalde inhoud en tooloutputs screenen voordat ze aan de context van het model worden toegevoegd, met dezelfde model-gebaseerde classifier die u op gebruikersinvoer toepast. De blinde vlek is anders omdat de bron anders is; identificeer het expliciet in uw controleontwerp om dekking te garanderen.

Op de API retourneren reacties een weigering wanneer streaming classifiers ingrijpen. De Messages API rapporteert dit als stop_reason: "refusal" vergezeld van een stop_details object (beschikbaar sinds Claude Opus 4. 7). Dat object draagt een beleidscategorie samen met een leesbare uitleg; beide velden zijn null wanneer de weigering niet aan een benoemde categorie is toegewezen. De categorieset is opgesomd in de stop-reasons documentatie op platform. claude. com. Op het moment van schrijven omvat het cyber, bio, frontier_llm en reasoning_extraction. Controleer de lijst opnieuw op publicatietijd in plaats van deze hard te coderen. Uw applicatie moet de categorie lezen en verschillende weigeringsklassen dienovereenkomstig routeren, in plaats van elke weigering als één ongedifferentieerd evenement te behandelen. Op modellen die stop_details niet retourneren, moet uw handler een afwezig object tolereren en terugvallen op generieke afhandeling. Verifieer huidige modelondersteuning tegen platform. claude. com op publicatietijd. Als regel, zodra een weigering is ontvangen, reset de gesprekscontext voordat u doorgaat: verwijder of herformuleer de beurt die de weigering triggerde, of wis de geschiedenis. Het verzenden van de volgende aanvraag op dezelfde geweigerde context retourneert verdere weigering.

Fail open versus fail closed: hoe uw guardrail-laag zich onder falen gedraagt Wanneer de operator-gebouwde classifier onder belasting een fout maakt, of uw operator-gebouwde screeningservice onbereikbaar is, doet de applicatie één van twee dingen. Het kan fail open en het verkeer ongeschermd doorlaten, of het kan fail closed en enige verdere acties blokkeren totdat de controle weer gezond is. De keuze behoort u toe als de Architect; dit zijn componenten die uw team bouwt, host en configureert. Ze zijn gescheiden van Anthropic's ingebouwde veiligheidscontroles van het model, die niet door de operator kunnen worden geconfigureerd en niet open falen. Een operator-gebouwde guardrail die stilzwijgend verkeer doorgeeft wanneer het een fout maakt, is erger dan één die verkeer blokkeert, omdat het u de geruststelling geeft van controle terwijl het geen bescherming biedt. Dit is dezelfde redenering als de circuit breaker uit het productiewerk: wanneer een afhankelijkheid in uw stack faalt, degrade opzettelijk op basis van de situatie.

Het volledige beveiligde aanvraagpad, als één systeem Een aanvraag beweegt door het pad in volgorde: het arriveert, inputscreening beslist of het het model bereikt, het model produceert een reactie, outputscreening beslist of die reactie wordt geretourneerd, en elke tooloproep die het model uitzendt, gaat door autorisatie voordat het loopt. Elke poort kan passeren, blokkeren of falen, en elke fout lost op in de richting die u koos. Elke geblokkeerde of falende poort wordt geregistreerd, zodat een incident uit het record kan worden gereconstrueerd.

Het volledige beveiligde aanvraagpad Gebruikersaanvraag → Input screening (model-gebaseerd voor ambigue intentie, deterministisch voor gedefinieerde regels, ingesteld om gesloten te falen) → Modeloproep → Output screening (judge model of validator, ingesteld om gesloten te falen) → Tool-call autorisatie (deterministische allowlist plus identiteit en scope) vóór enige side-effecting actie → Reactie aan gebruiker, met elke geblokkeerde of falende poort geregistreerd voor latere reconstructie

Skill supply-chain veiligheid U kunt de volgende bezwaar in het veld horen: "Skills zijn een black box. Ik kan niet alles erin zien totdat het loopt, dus hoe kan ik het vertrouwen? " De taak van de architect is een controle te bouwen die dit compenseert. Ter herinnering, skills zijn herbruikbare, distribueerbare code gekoppeld aan een instructieset, samen gebundeld en in uw omgeving gedropt. Dat distributiemodel is wat het een supply-chain risico maakt. Een niet-vertrouwde skill kan een code-execution exploit dragen: logica die commando's uitvoert, het netwerk bereikt of bestanden aanraakt op het moment dat het wordt aangeroepen. Dat is riskant omdat de skill verborgen schadelijke instructies kan bevatten die uw invoerfilters en promptscreening niet kunnen zien; deze kijken naar het gesprek, maar de bedreiging was stroomopwaarts in de skill ingebakken. Output monitoring zou een downstreameffect na het feit kunnen opvangen, maar tegen die tijd zal de code al zijn uitgevoerd. Dus, de verdediging moet eerder in de keten gaan. Voordat u een skill kunt vertrouwen en aanroepen, moet u deze controleren: open de bundel en lees deze op twee dingen. Ten eerste, zoek naar anomale oproepen: netwerkverzoeken, shell-uitvoering, bestandssysteemtoegang, referentielezingen. Ten tweede, out-of-scope operaties: gedrag dat niet overeenkomt met de taak die het beweert uit te voeren. Een opmaakskill die naar huis belt, is out-of-scope; een samenvatter die naar schijf schrijft, is out-of-scope. Het gestelde doel van een skill moet uw auditbasislijn zijn, en alles wat erbuiten gaat, is een bevinding die u moet onderzoeken. Uw audit vertelt u wat er in uw bundel zit; een skill die schoon review doorstaat, kan nog steeds bij runtime code ophalen die nooit in het pakket dat u las, was. Daarom moet de poort een net hebben. Voer skills uit met minimale bevoegdheden en in een sandbox die hen beperkte bestandstoegang, beperkt netwerk, geen permanente referenties die ze niet nodig hebben, geeft. De audit beslist wat erin gaat; runtime confinement bevat het als de audit iets mist. U moet beide gebruiken, omdat geen enkele controle perfect zal werken zonder de ander. U moet ook overwegen waar skills vandaan mogen komen; vertrouw alleen skills van een geverifieerde interne registry, geverifieerde uitgevers, alleen ondertekende releases. Een vertrouwde-bronbeleid verkleint het oppervlak dat u moet controleren en stopt niet-vertrouwde bundels voordat ze review bereiken. Één regel van openhartigheid geldt altijd: neem niet aan dat het platform skills voor u screent. Verifieer welke geautomatiseerde vetting eigenlijk bestaat; lees de documentatie, bevestig de reikwijdte van enige scanning, ontdek wat het wel en niet vangt. Elke audit moet eindigen in een expliciet geregistreerd oordeel: goedkeuren, afwijzen of herstellen. Goedkeuren betekent dat het schoon is en klaar voor gebruik. Afwijzen betekent dat het niet in de omgeving komt. Herstellen betekent dat u een oplosbaar probleem hebt gevonden; in dit geval, verwijder de aanstootgevende oproep, sandbox de operatie, pin een veiliger versie en controleer het opnieuw. Hoewel u misschien nooit alles ziet wat een skill kan doen, zijn het auditverdict en een vertrouwde-bronbeleid de compenserende controles die u verantwoord laten handelen.

Kosten · Complexiteit · Risico Kosten: Elke screeningpunt voegt een oproep of regelgebruik toe aan elke aanvraag. Een judge model op output verdubbelt ruwweg de modelkosten voor die beurt. Complexiteit: Drie controlpunten, elk met een controletype, een faaldirectie en een logline, zijn materieel meer om te bouwen en testen dan een enkel filter. Risico: Fail open is de kostbare fout: het systeem onderbelast laat stilzwijgend bescherming vallen terwijl het nog steeds beveiligd lijkt, dus de gat oppervlak alleen in een incident. Dit risico geldt niet voor Anthropic's API-level controles, die buiten uw configuratie vallen. Het geldt uitsluitend voor de componenten die uw team bouwt en bedient.

Screen 8: Wanneer een enkel outputfilter als een voltooid ontwerp lijkt

Watch OutGuardrails4 min Wanneer een enkel outputfilter als een voltooid ontwerp lijkt

Setup hook Output filtering is een duidelijke controle waar u naar kunt wijzen; het verschijnt als een schoon vak op het architectuurdiagram, het brandt waar een reviewer het kan zien werken, en het zit aan het einde van het pad waar het risico het meest concreet voelt, vlak voordat de gebruiker een reactie ziet. Dus, als u één classifier op de output toevoegt, ziet het diagram er compleet uit, en de review slaagt. Het probleem is dat het belangrijkste wat het systeem doet, misschien al is gebeurd voordat die classifier liep.

Een trace-fragment waar de side-effecting tool vóór enige controle van de aanvraag liep Het model ontving een aanvraag, riep een tool aan die een terugbetaling uitgeeft, en de tool liep. Een terugbetaling is een financiële actie: de tool keert een toeslag om en geeft geld van het bedrijf terug naar de rekening van de klant. Alleen nadat het geld was verplaatst, keek het outputfilter naar iets. Het inspecteerde de tekst die het model genereerde, vond niets onveilig en passeerde. De terugbetaling had al plaatsgevonden. Een controle zou op drie plaatsen op dit pad kunnen zitten: de aanvraag screenen op de manier in, de tooloproep autoriseren voordat deze werd uitgevoerd, en de reactie op de manier uit filteren. Dit systeem had alleen de laatste, en het zat stroomafwaarts van de enige actie op het pad die niet ongedaan kon worden gemaakt.

Een klantenserviceagent heeft toegang tot een issue_refund tool. Een gebruiker dient een aanvraag in. 1 aanvraag ontvangen (geen inputscreening geconfigureerd) 2 model zendt tool_use uit: issue_refund(order=…) 3 tool voert uit, terugbetaling uitgegeven (geen autorisatiepoort vóór de bijwerking) 4 outputfilter inspecteert gegenereerde tekst (het passeert, omdat de actie die het beschreef al was gebeurd)

Waarom dit faalde Een controle werd op één plaats geplaatst maar werd behandeld als dekking van drie plaatsen. Output screening beoordeelt tekst, niet acties. Een side-effecting tool heeft autorisatie nodig voordat het loopt, en een ongeschermde invoer heeft geen poort. Eén filter aan het einde is geen beveiligd pad, u moet alle drie filters toevoegen wanneer nodig.

Screen 9: Plaats de controles op het pad

CheckpointGuardrails4 min Plaats de controles op het pad Probeer het nu. U krijgt vier controles. Elk beantwoordt twee vragen: waar het op het aanvraagpad zit, en wat voor soort controle het is. Sleep elke controle op een raster. De horizontale as is het plaatsingspunt, van inputscreening tot actionautorisatie voordat een tool loopt, tot outputfiltering. De verticale as is of een deterministische controle of een model-gebaseerde controle past. Correcte plaatsing onthult de redenering. Niet elke zone zal worden gevuld, twee cellen zullen leeg blijven.

A. Jailbreak en prompt-injectie scherm B. Verboden termijnblocklist op het gebruikersbericht C. Toxiciteit judge op de gegenereerde reactie D. Terugbetalingsautorisatiebeleid controleren voordat de tool loopt

Model-gebaseerd Deterministisch

Input screening

Output screening

Action autorisatie

Controleer antwoorden Sla over voor nu

Screen 10: Waar ongelijke resultaten binnenkomen, en wat het systeem moet uitleggen

TeachingFairness11 min Waar ongelijke resultaten binnenkomen, en wat het systeem moet uitleggen Runtime controles stoppen niet-toegestane outputs van het systeem, zodat gebruikers ze nooit zien. Runtime controles houden echter geen rekening met een output die technisch elke controle doorstaat maar verschillende resultaten voor verschillende mensen oplevert. Die fout is moeilijker op te sporen en moeilijker toe te schrijven, omdat het op het oppervlak als een normale output lijkt.

Ongelijke resultaten komen op identificeerbare punten binnen Eerlijkheid wordt gemakkelijker om voor te ontwerpen zodra u stopt met het behandelen ervan als een enkel kenmerk van het model en begint het te behandelen als iets dat op specifieke, identificeerbare punten binnenkomt. In een Claude-systeem zijn er vier veel voorkomende ingang-punten:

De retrieval corpus kan groepen over- of ondervertegenwoordigen, dus de context die het model ziet, is al scheef. De framing van de prompt kan een aanname coderen die resultaten in één richting duwt. De voorbeelden die in few-shot prompting worden gebruikt, kunnen dezelfde scheefheid dragen als de corpus. En de downstream routing, wat er met de modeloutput gebeurt nadat deze is geproduceerd, kan sommige groepen naar verschillende paden sturen.

Elk van deze is een ingang-punt dat u kunt inspecteren, wat eerlijkheid een echte architectuurproperty maakt.

Wie vraagt bepaalt wat het systeem uitlegt

DoelgroepWat ze nodig hebbenWat dat van u vereist om vast te leggen

Een getroffen gebruiker Een duidelijke uitleg van waarom een beslissing die hen betreft werd genomen of uitgedrukt in termen waarop zij kunnen handelen. De invoer die de beslissing dreef en de reden waarom het resultaat werd bereikt, in een begrijpelijke vorm. Een regelgever Bewijs dat het systeem vergelijkbare zaken consistent behandelt en dat een specifieke beslissing op aanvraag kan worden gereconstrueerd. Een duurzaam, querybaar record van invoer, output en besluitpad. Uw bouwteam Genoeg detail om te vinden waarom een gemarkeerde beslissing fout ging en het op te lossen. Het volledige trace: prompt, opgehaalde context, modeloutput en elke routingstap, gekoppeld aan de bestaande observeerbaarheid.

Besluitregistratie is wat die verklaringen mogelijk maakt Om één beslissing opnieuw af te spelen en uit te leggen, leg vast de invoer die het dreef, de opgehaalde context, de modeloutput en de routing die het doorliep. Dit is dezelfde waarneembare instrumentatie uit het productiewerk, toegepast op een ander vraag. Deze keer, in plaats van te vragen of het systeem gezond is, vragen we waarom een specifieke beslissing is gebeurd. De instrumentatie is hetzelfde, maar de retentie en het querypad zijn anders.

Een eerlijkheids- en transparantiechecklist in actie Overweeg een kredietbeslissingsondersteunend systeem. Controleer de checklist eenmaal en de criteria stoppen met abstract te zijn:

Welk van de vier ingang-punten zou dit resultaat kunnen scheeftrekken, en is elk geinstrumenteerd? Voor een ongunstige beslissing, kunt u de invoer en de reden in termen produceren die de aanvrager kan optreden? Als een regelgever vraagt of vergelijkbare aanvragers gelijk werden behandeld, kunt u het log opvragen en een antwoord geven? Kan uw team het volledige trace voor enige gemarkeerde beslissing trekken?

Een 'nee' ergens is een ontwerggat.

Discernment: oordelen over outputs voor ongelijke behandeling Discernment is één van de vier AI Fluency competenties: AI-outputs en gedrag evalueren. In de praktijk betekent het oordelen of een modeloutput aanvaardbaar is, revisie nodig heeft of override nodig heeft in plaats van het te accepteren. Toegepast op eerlijkheid, is discernment wat een reviewer in staat stelt een scheef of ongerechtvaardigd resultaat te herkennen in plaats van alleen te bevestigen dat een waarde werd geproduceerd. Een transparantierecord is wat die herkenning in de eerste plaats mogelijk maakt.

Kosten · Complexiteit · Risico Kosten: Het vastleggen en behouden van besluitniveaulogboeken op elke aanvraag voegt opslag en een querypad toe, en de kosten groeien met verkeer in plaats van vast te blijven. Complexiteit: Het instrumenteren van vier ingang-punten en het bedienen van drie doelgroepen is meer ontwerpwerk dan een enkel auditlogboek, omdat elke doelgroep een ander segment van dezelfde record nodig heeft. Bovendien moet het retentiebeleid nu worden beheerst, omdat u besluitniveaugegevens langer en voor een specifiek doel vasthoudt. Risico: De uitkomstmetriek kan over het geheel goed lijken terwijl schade in één subgroep is geconcentreerd. Een niet-geregistreerd of niet-gemeten ingang-punt kan oneerlijkheid verbergen totdat iemand buiten het team het vindt. Gegevensafhandeling: Het besluitlogboek is zelf in scope voor het nalevingsregister. In HIPAA- of GDPR-contexten bevatten geregistreerde invoer en opgehaalde context gevoelige persoonlijke gegevens. Pas minimalisatie, retentielimieten en toegangscontroles toe op het logboek, en wijs het toe als een benoemde controle in uw nalevingsregister. Alles registreren voor transparantie en gegevens vastpinnen voor naleving zijn niet in conflict, omdat ze dezelfde logboek vereisen, anders beheerst.

Screen 11: Wanneer eerlijkheid wordt behandeld als het probleem van de modelprovider

Watch OutFairness3 min Wanneer eerlijkheid wordt behandeld als het probleem van de modelprovider

Setup hook Eerlijkheid kan lijken als een eigenschap van het model. De modelprovider trainde het, voerde de bias-evaluaties uit en publiceerde de resultaten, dus het voelt redelijk om eerlijkheid als iets af te handelen dat stroomopwaarts wordt afgehandeld voordat het model uw architectuur bereikt. Die framing houdt stand totdat uw systeem het model met uw eigen retrieval corpus koppelt, omdat een corpus die sommige zaken over-vertegenwoordigt, ongelijke resultaten oplevert die de modelprovider nooit heeft getest en niet kan zien.

Een post-incident review Dit foutpatroon is het waard om vroeg te herkennen; het team maakte een redelijke aanname die fout bleek te zijn. Ze gebruikten een model dat zijn eerlijkheidsevaluaties doorstond, en de scheefheid kwam op een punt waar ze niet op hadden gedacht te kijken. Wat volgt, is één architect die de gat in een post-incident review beschrijft. "We gingen ervan uit dat eerlijkheid de taak van het model was. De scheefheid zat in onze retrieval corpus, en we hadden zo weinig geregistreerd dat we het niet konden bewijzen. " De ongelijke resultaten kwamen niet uit de training van het model. In plaats daarvan kwamen ze uit een corpus die sommige zaken over-vertegenwoordigde, een ingang-punt dat het team nooit controleerde omdat ze eerlijkheid aan de leverancier hadden toegewezen. Toen de resultaten in twijfel werden getrokken, had het team geen besluitniveaulogboek om te reconstrueren wat was gebeurd. Ze konden noch de specifieke beslissingen verklaren die het systeem maakte, noch de corpus als oorzaak uitsluiten, wat hen onmogelijk maakte de enige vraag te beantwoorden die de regelgever stelde: waar kwam de scheefheid vandaan?

Waarom dit faalde Eerlijkheid werd behandeld als een modeleigenschap die de leverancier bezit. Ongelijke resultaten komen op punten die de architect controleert, en de retrieval corpus is één ervan. Zonder besluitregistratie op die punten, kon het team de schade niet verklaren of de bron ervan niet bewijzen. Eerlijkheid en verklaarbaarheid zijn architectuurvereisten. Instrumenteer ze op de punten waar scheefheid kan binnenkomen. Aannemen dat ze met het model arriveren, laat die punten ongecontroleerd.

Screen 12: Kritiseer het besluitregistratieontwerp

CheckpointFairness3 min Kritiseer het besluitregistratieontwerp Probeer het nu. U kijkt naar een systeemschets voor een besluitondersteunende stroom. Klik op de componenten waar transparantie ontbreekt of onvoldoende is, zoals een routingstap die nooit wordt geregistreerd of een beslissing die niet kan worden gereconstrueerd. Elke klik onthult wat die gat voor een getroffen gebruiker of regelgever betekent. Selecteer alle gaten. Laat voldoende geregistreerde componenten ongeselecteerd.

✓ GatEen routingstap die sommige zaken naar een ander pad stuurt zonder logvermelding.

↓

✓ GatEen retrieval stap waarvan de geretourneerde context niet wordt vastgelegd.

↓

✓ GatEen modeloutput opgeslagen zonder de invoer die het produceerde.

↓

✓ VoldoendeInvoer, outputs en routing zijn allemaal geregistreerd en gekoppeld aan een sessie-ID.

✓ VoldoendeHet logboek is querybaar per beslissing en behouden voor 90 dagen.

✓ GatEen geaggregeerd nauwkeurigheidsdashboard zonder per-subgroepuitsplitsing.

Controleer antwoorden Sla over voor nu

Screen 13: Routeer beslissingen naar mensen op basis van inzet, niet op volume

TeachingReview routing10 min Routeer beslissingen naar mensen op basis van inzet, niet op volume Besluitregistratie gaf u een record van wat elke geautomatiseerde beslissing op was gebaseerd: de invoer die het zag, het pad dat het nam en de output die het produceerde. Een geregistreerde beslissing kan achteraf worden uitgelegd, maar een logboek alleen beslist niet welke beslissingen een persoon vóór ze effect hebben moet wegen. Een logboek legt beslissingen achteraf uit. Een routeringsregel stopt de verkeerde voordat ze effect hebben. U werkt uit welke beslissingen menselijke review verdienen en wat die reviewer op het scherm moet zien om snel de oproep te doen. Het logboek dat u al hebt gebouwd, is het grondstof voor die weergave, dus dit is een kwestie van bepalen wat ervan op te oppervlak en wanneer, in plaats van het systeem opnieuw van nul af aan te instrumenteren.

Wat de inzet van een beslissing bepaalt Denk aan menselijke review als een budget: u hebt een eindige hoeveelheid reviewer aandacht, en u moet het op de items met de hoogste inzet richten. De volgende variabelen werken samen om de inzet van een beslissing in te stellen.

Reversibiliteit is hoe gemakkelijk een verkeerde beslissing ongedaan kan worden gemaakt. De kosten van een verkeerde beslissing is wat de fout veroorzaakt als het onverbeterd doorloopt. Deze twee stellen de inzet van de beslissing in: een keuze die moeilijk om te keren is en duur wanneer fout, is hoge inzet, ongeacht hoe het systeem eraan komt. Vertrouwen is de derde variabele die op de andere twee zit. Het is de score die het systeem over zijn eigen output produceert, en het is nuttig alleen voor zover het is gekalibreerd, omdat een model zelfverzekerd fout kan zijn. Vertrouwen verandert niet de inzet van een beslissing; het schat in hoe waarschijnlijk deze output fout is, wat u vertelt hoeveel van uw volume u voor review naar een persoon moet routeren.

Combineer deze variabelen in één regel: routeer beslissingen naar een persoon wanneer ze laag-vertrouwen en ofwel irreversibel of hoog-kosten zijn; laat zelfverzekerde, reversibele, lage-kosten beslissingen door. Een zelfverzekerde, gemakkelijk omgekeerde, lage-kosten beslissing kan meestal zonder menselijke tussenkomst lopen. Een laag-vertrouwen, irreversibele, hoog-kosten beslissing heeft bijna altijd menselijke review nodig. De beslissingen die uw reviewbudget verbruiken, zijn die waar deze variabelen het niet eens zijn. Een zaak kan hoog-kosten maar gemakkelijk reversibel zijn, of laag-vertrouwen op iets triviaals om om te keren. Wanneer ze conflicteren, geef groter gewicht aan kosten en reversibiliteit, omdat ze de gevolgen van een fout bepalen. Laat vertrouwen bepalen hoeveel van dat hoog-inzet volume u veilig onbeoordeeld kunt laten. Routering op vertrouwen draagt één aanname die het waard is om te identificeren: het vertrouwenssignaal moet voor de regel worden gekalibreerd, en het bevestigen van die kalibratie is een taak op zichzelf.

Waar de menselijke zit, is een afweging tussen veiligheid en snelheid Zodra een beslissing naar een persoon wordt gerouteerd, kiest u waar zij in de stroom zitten. Een menselijke eerder betrekken is veiliger en langzamer.

PlaasingWat het u geeftWat het kost

Pre-action goedkeuringDe actie kan niet effect hebben totdat een persoon het goedkeurt, dus niets irreversibels gebeurt onbeoordeeld. Het voegt latentie toe aan elke gerouteerde beslissing en een persoon moet beschikbaar zijn, dus het schaalt niet naar hoog volume. Post-action auditDe actie loopt onmiddellijk en een persoon beoordeelt het achteraf, dus doorvoer blijft hoog. Een verkeerde actie heeft al effect gehad op het moment dat het wordt opgemerkt, dus het past alleen bij reversibele, lagere-kosten beslissingen. Sampled reviewEen fractie van beslissingen wordt beoordeeld om kwaliteit te controleren zonder het algehele proces te vertragen. Een slechte beslissing kan onbemonsterd door glippen, het controleert het systeem in plaats van individuele resultaten te bewaken.

Wat de reviewer ziet, bepaalt of review nauwkeurig is Een reviewer die niet kan zien waarom een beslissing in hun wachtrij terechtkwam, kan zonder de beoordeling die het nodig had goedkeuren. Zorg ervoor dat uw reviewers drie dingen hebben: de invoer die de beslissing dreef, de modeloutput en de reden waarom het werd gemarkeerd. Zonder deze reden kunnen ze het verschil niet zien tussen een randgeval en routineverkeer. Zonder de invoer kunnen ze niet zien of de output correct is. Wat u voor de reviewer zet, bepaalt of de review nauwkeurig is.

Anthropic's onderzoek naar agent autonomie vond dat handtekening op elke actie vereisen wrijving toevoegt zonder betekenisvolle veiligheidswins. Een betere benadering is dat een persoon controleert wat er gebeurt en ingrijpt wanneer nodig. Eén Anthropic patroon in agent workflows is per-stap goedkeuringen verminderen en review naar hogere-waarde checkpoints verplaatsen, zoals planreview of uitzonderingsafhandeling, om toestemmingsmoeheid te voorkomen; het exacte reviewontwerp hangt af van het risico van de workflow. Zonder deze discernment kan toestemmingsmoeheid gebeuren. Toestemmingsmoeheid is wanneer een systeem tientallen keren achter elkaar om goedkeuring vraagt, en reviewers beginnen items door te klikken en goed te keuren zonder te lezen of de kwaliteit van review te geven die nodig is. Dat patroon is wat tot planreview in Claude Code leidde, waar een persoon het plan goedkeurt in plaats van elke stap. Verifieer huidige framing tegen anthropic. com/research/measuring-agent-autonomy en anthropic. com/research/trustworthy-agents op publicatietijd.

Diligence: de competentie achter menselijke review Diligence is één van de vier AI Fluency competenties: verantwoorde AI-samenwerking garanderen. Toegepast op implementatie, betekent het expliciete menselijke verantwoordingscontrolepunten handhaven, herkennen wanneer automatiseringsdruk toezicht erodeert, en workflows controleren op gaten waar AI zonder review handelt, vooral naarmate automatisering schaalt. Voor agent workflows, wordt de routeringsregel een checkpointpatroon: een poort die uitvoering pauzeert voor menselijke review op basis van dat taakrisico en reversibiliteit. Plaats een poort vóór enige irreversibele of hoog-inzet actie die een agent anders autonoom zou nemen, en bemonsterde lagere-inzet acties in plaats van elke poort. Dit is dezelfde poortwoordenschat waarop multi-agent ontwerp afhangt.

Kosten · Complexiteit · Risico Kosten: Pre-action review voegt latentie toe aan elke gerouteerde beslissing en heeft reviewertijd nodig, wat een terugkerende bedrijfskosten is. Complexiteit: Routeringslogica, een reviewer interface die invoer en vlagredenen toont, en drie plaatsingspaden zijn complexer om te bouwen dan een enkele reviewwachtrij. Risico: Routering op volume in plaats van inzet overspoelt reviewers en risico's reviewkwaliteitsdegradatie, of staat een hoog-inzet, irreversibele actie zonder poort toe.

Screen 14: Wanneer alles naar review routeren review betekenisloos maakt

Watch OutReview routing3 min Wanneer alles naar review routeren review betekenisloos maakt

Setup hook Bepalen welke beslissingen als hoog-inzet tellen, vereist oordeel, en alles naar review sturen verwijdert die cruciale stap. Het voelt misschien als de conservatieve standaard: het is gemakkelijk te verdedigen tegen een nalevingsreviewer of auditor, en het vereist geen oproep over waar de inzet zit. Alles routeren voelt als het veilige antwoord precies omdat het u van het trekken van de lijn spaart.

Een korte transcriptie van een handoff die slordig werd beoordeeld De wachtrij van een reviewer wordt zelden gezien totdat het faalt. Het patroon hieronder toont wat gebeurt wanneer een systeem elke output naar een persoon routeert en die persoon niets geeft om tegen te beoordelen. Twee aparte dingen gaan tegelijk fout, en de dialoog oppervlakt beide: het volume is meer dan iemand kan lezen, en elk item arriveert zonder de context die de reviewer zou laten oordelen.

Reviewer: Er zijn vandaag vierhonderd items in mijn wachtrij. Hetzelfde als gisteren. Lead: Lees je de invoer op elk ervan? Reviewer: Dat kan niet. Ik krijg de output en een goedkeuringsknop, dat is alles. Ik zie niet eens de invoer, of waarom dit ervan bij mij terechtkwam. Na het eerste uur moet ik gewoon goedkeuren om het tempo bij te houden.

Het ontwerp stuurde alle outputs voor review en gaf de reviewer alleen de output, zonder invoer en geen vlagrede. Het volume maakte zorgvuldige review onmogelijk, en de ontbrekende context maakte het zinloos, dus review stortte in tot goedkeuring. Een hoog-inzet beslissing in die wachtrij kreeg dezelfde routinegoedkeuring als een triviale.

Waarom dit faalde Twee onafhankelijke fouten stapelden zich hier, en elk alleen is genoeg om review slordig te maken. De eerste is volume. Wanneer het aantal items dat naar een persoon wordt gerouteerd, meer is dan wat ze in de tijd die ze hebben kunnen lezen, dekt toezicht dat alles dekt niets, omdat de reviewer zich disengageert om bij te houden. De fix is de routeringsregel: stuur beslissingen naar een persoon op inzet, met vertrouwen, reversibiliteit en kosten, zodat de wachtrij alleen de beslissingen bevat die aandacht verdienen in plaats van allemaal. De tweede is ontbrekende context. Een reviewer die alleen de output en een goedkeuringsknop ziet, heeft niets om de output tegen te controleren, dus zelfs een korte wachtrij is moeilijk nauwkeurig te beoordelen. De fix is te verschuiven wat in de reviewerweergave zit: oppervlak de invoer waarop de beslissing was gebaseerd en de reden waarom het item werd gemarkeerd, zodat de reviewer kan zien wat hen wordt gevraagd te wegen. Als u slechts één van deze fouten repareert, is het nog steeds mogelijk dat de review faalt. Een kleine wachtrij zonder context en een goed gebouwde reviewer view verdrinken in volume beide falen.

Screen 15: Bouw de review-routeringsregel

CheckpointReview routing3 min Bouw de review-routeringsregel Probeer het nu. Een routeringsregel heeft drie controles: een vertrouwensdrempel, de kosten van een fout antwoord en een reversibiliteitsinstellingen. Het doel is hoog-inzet, laag-vertrouwen beslissingen naar een persoon vóór effect te routeren, terwijl de reviewwachtrij onder het reviewerplafond blijft. Kies de regel die beide doelen tegelijk bereikt.

A. Routeer alles onder een hoog vertrouwensdrempel naar review, ongeacht inzet. B. Routeer beslissingen die laag-vertrouwen EN ofwel irreversibel of hoog-kosten zijn naar pre-action review; laat zelfverzekerde, reversibele, lage-kosten beslissingen door. C. Routeer op vertrouwen alleen, ingesteld laag genoeg om de wachtrij klein te houden. D. Stuur elke beslissing naar review om veilig te zijn.

Nu voltooi deze stap: In 1–2 zinnen, noem de enige beslissende controle, wat maakt dat een laag-vertrouwen zaak nog naar een persoon routeert zelfs wanneer vertrouwen binnen tolerantie is?

Onthul modelantwoord

Modelantwoord Reversibiliteit en de kosten van een fout antwoord zijn de beslissende controles, niet vertrouwen. Vertrouwen filtert het volume dat u routeert, maar het verandert niet de inzet van de beslissing. Een zaak kan zelfverzekerd zijn en toch naar een menselijke routeren als het irreversibel of duur genoeg is om het te rechtvaardigen.

Markeer voltooid

Sla over voor nu

Screen 16: Elke nalevingsverplichting in een controle met bewijs omzetten

TeachingCompliance10 min Elke nalevingsverplichting in een controle met bewijs omzetten De nalevingslaag van het integratiemodel gebruikte de regelgevende verplichting als een pre-filter: HIPAA, GDPR, FedRAMP, advocaat-cliëntprivilege of een gegevensresidentiëbeleid elk regeerde leveringsroutes en ingang-punten in of uit voordat kosten of engineeringvoorkeur het gesprek binnenkwam. Dat werk brengt u naar een ingang-punt en een route die de verplichting overleeft, maar de volgende stap is smaller en moeilijker. Elke overgebleven verplichting moet nu een controle met een benoemde eigenaar worden. Een reviewer behandelt een nalevingsingang-punt alleen niet als bewijs dat de regel wordt gevolgd. Ze vragen ook wie de controle bezit en wat bewijs toont dat het in de praktijk wordt gehouden.

Een regelgeving stelt een resultaat, maar u levert de controle en het bewijs dat het werkt Kaders zoals GDPR, HIPAA en FedRAMP stellen resultaten, niet implementaties. Ze zeggen wat waar moet zijn: dat beschermde gegevens op een bepaalde manier moeten worden afgehandeld, dat toegang moet worden gecontroleerd en dat verwerking in een geautoriseerde omgeving moet plaatsvinden, maar ze laten de technische controle aan u. Elke verplichting wordt drie dingen die u bezit: een specifieke technische controle die het resultaat bereikt, een eigenaar die ervoor verantwoordelijk is, en een bewijsartefact dat toont dat het live is. Onthoud altijd het bewijsartefact op te nemen; dit is wat de reviewer zal controleren en is het meest gemist.

Verplichtingen toewijzen aan controles, eigenaren en bewijs Verplichtingen toewijzen aan controles, eigenaren en bewijs Verplichting (kader) Technische controle Bewijs dat een reviewer accepteert Eigenaar

Beschermde gezondheidsgegevens afgehandeld onder een overeenkomst (HIPAA) Gebruik alleen een HIPAA-klaar Enterprise-plan of first-party API-configuratie gedekt door een ondertekende Business Associate Agreement, met HIPAA-naleving ingeschakeld en alleen in-scope functies. De ondertekende BAA en de admin-instelling met HIPAA-naleving ingeschakeld, plus de in-scope functielijst. Veiligheidslead US-overheidsworkload op het vereiste impactniveau (FedRAMP) Lever via een Anthropic-gedocumenteerde geautoriseerde route die het vereiste impactniveau bereikt, niet een niet-geautoriseerde ingang-punt. Het autorisatierecord voor de gekozen route en bevestiging dat de workload uitsluitend erop loopt. Platform eigenaar Gegevens afgehandeld en opgeslagen in een goedgekeurd gebied (gegevensresidentialiteit) Configureer ondersteunde regionale verwerking en opslag voor het goedgekeurde gebied, en valideer of logboeken, caches, monitoring en retentiepaden binnen de goedgekeurde grens blijven. De residentialiteitsconfiguratie en een gegevensstroom-record met waar elke kopie leeft. Gegevenseigenaar Beslissingen reconstructeerbaar op aanvraag (transparantie, cross-kader) De besluitregistratie gebouwd in de eerlijkheidscluster, behouden en querybaar voor de vereiste periode. Een steekproefreconstuctie van één beslissing uit het live logboek. Architect

Training use versus retentie, twee verschillende claims Verwar training use en retentie niet in dezelfde claim: gegevens kunnen standaard van modeltraining worden uitgesloten terwijl ze nog steeds worden behouden of gemonitord voor logging, misbruikpreventie, wettelijke naleving of geconfigureerde auditdoeleinden.

Het bewijsartefact is wat de handoff effectief maakt De constraint-eliminatiedenken uit het integratiewerk gaat hier voort. Toen elimineerde u leveringsroutes die een constraint niet konden overleven. Nu registreert u, voor elke verplichting, de controle die het bevredigt en het artefact dat het bewijst. Een veiligheids- en juridische reviewer accepteert bewijs dat een controle live is: een ondertekende overeenkomst, een configuratiescherm, een autorisatierecord of een geretourneerde logquery. Wat ze niet accepteren, is een ontwerpdocument dat een controle identificeert zonder eigenaar en zonder bewijs; een controle die niemand kan aantonen werkt, is niet te onderscheiden van één die niet loopt.

Kosten · Complexiteit · Risico Kosten: Het produceren en onderhouden van bewijs voor elke verplichting is voortdurend werk. Configuraties drijven af en artefacten worden oud, dus het register wordt op regelmatige cadentie opnieuw gevalideerd. Complexiteit: Een controle, een eigenaar en een levend bewijsartefact per verplichting is meer governance dan een ingang-puntkeuze, en het omvat veiligheids-, juridische en platformeigenaren die elk moeten akkoord gaan over wie wat houdt. Risico: Een controle gespecificeerd zonder eigenaar en zonder bewijs is onzichtbaar bij de audit. Het kan niet-operationeel gaan zonder dat iemand verantwoordelijk is, en de gat oppervlak in review in plaats van in ontwerp, wat de duurste plaats is om het te vinden.

Screen 17: Wanneer het doorstaan van ingang-puntselectie voelt als het voltooien van naleving

Watch OutCompliance3 min Wanneer het doorstaan van ingang-puntselectie voelt als het voltooien van naleving

Setup hook Het doorstaan van de constraint pre-filter en het kunnen bewijzen van naleving zijn twee verschillende dingen. De pre-filter geeft u een schoon signaal. Het kiezen van een leveringsroute die HIPAA, GDPR of FedRAMP overleeft, produceert een onmiddellijk, zichtbaar resultaat: de route is toegestaan, het ingang-punt is vrijgegeven, het ontwerp kan voortgaan. Het bewijzen dat elke verplichting wordt nageleefd, produceert niets zichtbaars op ontwerptijd, omdat het bewijs een artefact is dat u moet bouwen, aan een eigenaar moet hechten en levend moet houden naarmate configuraties veranderen. Die gat is gemakkelijk te missen, omdat het moment dat voelt als een finishlijn en het moment dat een reviewer controleert, vaak maanden uit elkaar liggen.

Een implementatie die de juiste route koos maar geen bewijs produceert Een team selecteerde een nalevingsroute voor een gereglementeerde workload en behandelde naleving als afgehandeld. Ze hadden verplichtingen eenmaal op ontwerptijd aan controles toegewezen, in een document. Geen eigenaar was aan de controles gehecht, en geen logging was ingebouwd om aan te tonen dat enige controle werkte. De gegevensresidentialiteitsverplichting is waar de fout zich concentreerde. De controle was correct op papier: verwerking vastgepind aan het goedgekeurde gebied. Echter, maanden later veranderde een logconfiguratie en begon aanvraagmetadata naar een winkel in een tweede gebied te schrijven. Niets identificeerde de verandering, omdat niemand gegevensresidentialiteitcontrole bezat en geen artefact bijhield waar gegevens landden. De gat oppervlak bij de audit, niet bij ontwerp, toen een reviewer om bewijs vroeg dat gegevens in-regio bleven en het team een ontwerpdocument had in plaats van een gegevensstroom-record.

Waarom dit faalde Het overleven van de pre-filter werd verward met het vaststellen van naleving. Een nalevingsroute is een vereiste, geen bewijs. Elke verplichting heeft een controle, een benoemde eigenaar en een levend bewijsartefact nodig dat opnieuw wordt gevalideerd naarmate de implementatie verandert. De residentialiteitcontrole in dit verhaal was echt op ontwerptijd en stilzwijgend onwaar in productie, en niets ving het verschil omdat geen artefact het controleerde.

Screen 18: Rechtvaardigen de controlekeuze

CheckpointCompliance3 min Rechtvaardigen de controlekeuze Probeer het nu. U krijgt één nalevingsverplichting voor een gereglementeerde implementatie. Kies de technische controle die het bewijst, selecteer dan de enige last-dragende reden waarom een veiligheids- en juridische reviewer die controle als bewijs zou accepteren. U slaagt alleen wanneer beide landen: de controle moet bij de verplichting passen, en u moet noemen waarom het als bewijs telt dat een reviewer kan inspecteren. Verplichting: Beschermde gezondheidsgegevens moeten onder een formele overeenkomst worden afgehandeld (HIPAA).

A. Een HIPAA-klaar plan of first-party API onder een ondertekende BAA, omdat de ondertekende overeenkomst plus de ingeschakelde configuratie het artefact is dat een reviewer als bewijs kan inspecteren. B. Een HIPAA-klaar plan onder een ondertekende BAA, omdat het model wordt geïnstrueerd om gezondheidsgegevens zorgvuldig af te handelen. C. Een model-gebaseerde inhoudsfilter op gezondheidstermen, omdat het gevoelige gegevens bij runtime vangt.

Controleer antwoord Sla over voor nu

Screen 19: Monteer een verantwoorde implementatie

CumulativeModule8 min Monteer een verantwoorde implementatie Probeer het nu. U krijgt een zelfstandige briefing, en u maakt vijf opeenvolgende beslissingen die een verantwoorde implementatie bouwen. De beslissingen lopen in volgorde omdat elk de voorwaarden voor de volgende bepaalt. Een zwakke vroege keuze beperkt wat de latere kunnen doen. Als u een domeinregel in getraind gedrag in beslissing één achterlaat, is er geen laag stroomafwaarts die het terug kan zetten.

U bouwde elke laag op zichzelf over de module. Hier is de stapel die u monteert, in volgorde:

Getraind gedrag vormt basisveiligheid; uw toepassingsbeleid definieert domein-specifieke regels; de runtime controles hieronder dwingen die regels in werking af. Runtime screening en autorisatie zitten op het aanvraagpad en stoppen niet-toegestane inhoud en niet-toegestane acties. Eerlijkheids- en transparantiecontroles behandelen ongelijke resultaten bij hun bron en zorgen ervoor dat elke beslissing achteraf kan worden gereconstrueerd. Ze hangen af van effectieve logging. Menselijke review routing stuurt de beslissingen die een model niet alleen moet finaliseren naar een persoon, op inzet. Het hangt af van dezelfde logging. Het controleregister bindt elke verplichting aan een controle, een eigenaar en een bewijsartefact.

De briefing Een openbare-sector voordelen assistent helpt een agentschap bepalen programma-geschiktheid, aanbevelend of goed te keuren, af te wijzen of door te verwijzen. De briefing geeft u wat de beslissingen nodig hebben en niets meer: Kader: FedRAMP op het vereiste impactniveau van het agentschap, plus de regel van het agentschap dat een afgewezen aanvrager de specifieke reden krijgt. Hoog-inzet, laag-vertrouwen zaak: Een aanvrager dicht bij de geschiktheidsdrempel met onvolledige documentatie, waar een verkeerde afwijzing iemands voordelen verwijdert. Scheef-gevoelige output: De aanbeveling en de reden gehecht aan een afwijzing. Gegevens: Aanvrager-ingediende velden, agentschapsrecords opgehaald op besluitmoment en alle afgeleide functies.

Stel de grens tussen getraind gedrag en uw applicatielaag in.

Plaats de runtime controles.

Geef de eerlijkheids- en transparantiecontroles op.

Definieer de menselijke-review routing.

Bouw het controleregister.

Onthul modelantwoord Sla over voor nu

Modelantwoord

Stel de grens tussen getraind gedrag en uw applicatielaag in. Getraind gedrag weigert brede schadeklassen maar zag dit programma's geschiktheidsregels nooit, dus die behoren tot de applicatielaag. Laat ze in getraind gedrag en geen controle stroomafwaarts kan ze bereiken.
Plaats de runtime controles. Positioneer inputscreening, outputscreening en tool-call autorisatie, kies model-gebaseerd of deterministisch op elk, en stel de faaldirectie in. Fail gesloten, omdat een scherm dat open faalt een ongeschermde afwijzing naar een aanvrager laat bereiken.
Geef de eerlijkheids- en transparantiecontroles op. Noem welk van de vier ingang-punten (corpus, promptframing, voorbeelden, routing) dit resultaat zou kunnen scheeftrekken, en bouw de besluitregistratie eenmaal, omdat de getroffen aanvrager, de regelgever, het bouwteam en het controleregister er allemaal op trekken.
Definieer de menselijke-review routing. Routeer op vertrouwen, reversibiliteit en kosten van een fout antwoord, en kies een plaatsing: pre-action goedkeuring, post-action audit of sampled review. Stuur een laag-vertrouwen, moeilijk-om-te-keren afwijzing naar pre-action goedkeuring. Sleutel de regel aan inzet, niet volume, of een stille wachtrij golft een hoog-inzet afwijzing door.
Bouw het controleregister. Wijs elke FedRAMP-verplichting toe aan een controle, een eigenaar en het bewijs dat een reviewer accepteert. Een controle zonder bewijsartefact is een claim die u niet kunt bewijzen werkte.

Sterke antwoorden zijn specifiek: ze noemen welke ingang-punten, noemen de faaldirectie, noemen de routeringsregelvariabelen en noemen het bewijsartefact. Zwakke antwoorden beschrijven het algemene concept zonder het op deze implementatie toe te passen. Controleer elke beslissing tegen de briefing, de nalevingskader en de hoog-inzet zaakdetails moeten in uw antwoorden verschijnen.

Markeer voltooid

Screen 20: Woordenlijst

ReferenceWrap-up Woordenlijst De sleuteltermen die in deze module worden gebruikt, in alfabetische volgorde. Klik op een term om de definitie uit te breiden.

BAA (Business Associate Agreement) Een contract onder HIPAA dat een leverancier toestaat beschermde gezondheidsgegevens namens een gedekte entiteit te verwerken, waarbij de veiligheidsmaatregelen en aansprakelijkheden van elke partij worden gedefinieerd. Zonder het is het afhandelen van die gegevens via de leverancier niet nalevingsgericht ongeacht de technische controles. Toestemmingsmoeheid De afbraak van toezicht wanneer een reviewer wordt gevraagd te veel acties goed te keuren, dus ze keuren bijna alles goed zonder echte review. Het is het foutpatroon van het routeren van elke beslissing naar een menselijke. Verifieer Anthropic's huidige framing tegen anthropic. com. Grondwet Het geschreven document dat Anthropic tijdens training gebruikt om Claudes waarden en gedrag te vormen, stellende een prioriteitsvolgorde van breed veilig, ethisch, nalevingsgericht met richtlijnen en echt behulpzaam. Het vormt het getrainde gedrag van het model maar codeert geen implementatie-specifiek domeinbeleid. Verifieer de huidige versie tegen anthropic. com. Controleregister Een tabel die elke nalevingsverplichting aan zijn technische controle, een verantwoordelijke eigenaar en een bewijsartefact bindt, zodat een gereglementeerde implementatie als register kan worden gecontroleerd in plaats van als narratief te worden gesteld. Gegevensresidentialiteit De vereiste dat gegevens binnen een gespecificeerd geografisch gebied worden verwerkt en opgeslagen, inclusief kopieën in logboeken en caches. Het is de controle achter veel gegevenssouvereiniteitsverplichting. Besluitregistratie Het vastleggen van de invoer, opgehaalde context, modeloutput en routing voor elke beslissing, gesleuteld zodat één beslissing later kan worden afgespeeld en uitgelegd. Het is dezelfde waarneembare instrumentatie gericht op de vraag waarom een specifieke beslissing is gebeurd. Bewijsartefact Het concrete bewijs dat een veiligheids- en juridische reviewer accepteert dat een controle live is: een ondertekende overeenkomst, een configuratiescherm, een autorisatierecord of een geretourneerde logquery. Een controle genoemd in een ontwerpdocument zonder artefact is een claim, geen bewijs. Fail open versus fail closed Hoe een guardrail zich gedraagt wanneer het zelf een fout maakt. Fail open geeft verkeer door ongeschermd, terwijl fail closed blokkeert totdat de controle gezond is. Voor veiligheidscontroles is fail closed de opzettelijke keuze, omdat een controle die stilzwijgend verkeer doorgeeft geen bescherming biedt. FedRAMP De FedRAMP classificatie (laag, matig of hoog) die de veiligheidscontroles bepaalt die een cloudservice moet bereiken om US-overheidsworkloads van een gegeven gevoeligheid af te handelen. Het vereiste niveau wordt door de workload bepaald, en de leveringsroute moet op of boven het niveau worden geautoriseerd. GDPR De gegevensbeschermingswet van de EU met betrekking tot hoe organisaties persoonlijke gegevens van mensen in de EU en EER verzamelen, verwerken, opslaan en overdragen. Het verleent individuen rechten over hun gegevens en vereist een wettelijke basis voor verwerking, gegevensminimalisatie en bescherming. HIPAA Een Amerikaanse federale wet die normen stelt voor het beschermen van gezondheidsgegevens van individuen. Het bepaalt hoe beschermde gezondheidsgegevens (PHI) door gedekte entiteiten en hun zakelijke partners worden gebruikt, openbaar gemaakt en beveiligd. Wanneer een leverancier PHI namens een gedekte entiteit verwerkt, vereist HIPAA een Business Associate Agreement (BAA) die de veiligheidsmaatregelen en aansprakelijkheden van elke partij definieert. In deze module drijft het de vereiste om via een HIPAA-klaar plan of first-party API onder een ondertekende BAA te leveren. Human-in-the-loop routing Een regel die beslissingen naar een persoon routeert op basis van vertrouwen, reversibiliteit en de kosten van een fout antwoord, in plaats van op volume, met de reviewer pre-action, post-action of in een steekproef geplaatst. Ingang-punt (eerlijkheid) Een specifieke plaats waar ongelijke resultaten een systeem kunnen binnenkomen: de retrieval corpus, de promptframing, de gekozen voorbeelden of de downstream routing. Ze noemen maakt eerlijkheid een architectuurproperty die u kunt instrumenteren in plaats van een modeleigenschap die u aanneemt. Input screening Een controle die vóór de modeloproep loopt om te bepalen of een aanvraag het model moet bereiken, met een model-gebaseerde classifier voor fuzzy intentie zoals jailbreaks of een deterministische regel voor crisp patronen. Judge model Een model dat wordt gebruikt om een ander model's output te scoren of classificeren, voor kwaliteiten zoals toxiciteit of nalevingsbeleid die een deterministische regel niet betrouwbaar kan coderen. Het kan worden omzeild, daarom wordt het met deterministische controles in serie geketend. Output screening Een controle die vóór de reactie de gebruiker bereikt loopt, de gegenereerde inhoud met een model voor kwaliteiten zoals toxiciteit of een validator voor bekende strings en schemaschendingen beoordelend. Tool-call autorisatie Een controle vóór enige actie met bijwerking die bepaalt of deze beller deze actie in deze context mag uitvoeren. Het moet deterministisch zijn, een allowlist plus identiteit en scope, zodat de beslissing bewijsbaar en controleerbaar is. Training-time alignment versus inference-time control Training-time alignment is het veilige gedrag ingebakken in het model voor elke gebruiker. Inference-time control is de screening en autorisatie die u op aanvraagmoment toevoegt om regels specifiek voor uw implementatie af te dwingen. Het verwarren van de twee laat implementatie-specifieke regels onafdwingbaar.

Screen 21: Vijf dingen die overal hier gelden

RecapModule3 min Vijf dingen die overal hier gelden

Veiligheid is een stapel lagen, niet een instelling Training reduceert breed schadelijk voor elke aanvraag maar zag nooit het domeinbeleid, gegevensregels of autorisatiemodel van uw partner, dus trek de grens expliciet en identificeer wat elke laag dekt. De gevaarlijke fout is stil: aannemen dat Claude een regel afdwingt die niet in een laag leeft.

Een beveiligd pad heeft drie controlpunten en een gekozen faaldirectie Input screening, output screening en tool-call autorisatie beantwoorden verschillende vragen, dus slechts één filter aan het einde dekt de andere twee niet. Laat controlerrors fail closed voor beslissingen waar een verkeerde pass schade veroorzaakt, omdat een guardrail die stilzwijgend verkeer doorgeeft u de schijn van bescherming geeft zonder enige functie.

Eerlijkheid en transparantie zijn geinstrumenteerd, niet aangenomen Ongelijke resultaten ontstaan op punten die u controleert, zoals de corpus, promptframing, voorbeelden en routing, dus eerlijkheid als verantwoordelijkheid van de leverancier behandelen, laat die punten ongecontroleerd. Registreer elke beslissing zodat gebruikers, regelgevers en uw team het kunnen reconstrueren. Als u een verklaring niet kunt reconstrueren, kunt u er niet betrouwbaar één geven.

Routeer review op inzet, niet op volume Vertrouwen, reversibiliteit en de kosten van een fout antwoord bepalen welke beslissingen een persoon moet beoordelen, dus stuur de hoog-inzet, laag-vertrouwen naar een menselijke met de invoer en de vlagrede en laat de rest door. Alles routeren overspoelt de wachtrij totdat reviewers doorheen klikken zonder te lezen.

Een nalevingsingang-punt is een vereiste, en een bewijscontroleset is het bewijs Een regelgeving stelt een resultaat en laat u de controle, dus zet elke verplichting in een specifieke controle, een benoemde eigenaar en een levend bewijsartefact dat u in de loop van de tijd opnieuw valideert. Een controle zonder eigenaar en zonder bewijs gaat uiteindelijk niet-operationeel en faalt bij de audit, omdat wat een reviewer accepteert bewijs is dat de controle live is, niet de controle zelf.

Wat komt volgende De volgende module verschuift van het bouwen van een verantwoorde implementatie naar het overdragen en beheren ervan. U neemt de architectuur die u nu kunt bewijzen en communiceert de afwegingen ervan aan niet-technische belanghebbenden, documenteert het naar een standaard en beheert het door de discovery-to-hand-off levenscyclus. Het controleregister en de gelaagde grens die u hier bouwde, worden de documentatie en de basislijn waarop handoff rust.

Bronnen

Building with the Claude API (Skilljar Course 4), gebruikt voor modelbeoordelaars, tool-call mechanica, gestructureerde outputs en het evaluatorpatroon. platform. claude. com/docs en platform. claude. com, gebruikt voor inhoudsmatig, de guardrails gids, streaming weigering en gestructureerde outputs. anthropic. com, gebruikt voor de grondwet van januari 2026 en huidige veiligheidspositie. Anthropic Trust Center en Privacy Center, gebruikt voor HIPAA, FedRAMP en gegevensresidentialiteitspositie. Architect M1 en M2 storyboards, gebruikt om in plaats van opnieuw te onderwijzen eigenaarstoewijzing, referentiearchitecturen, model- en contextstrategie, evals, integratielagen en observeerbaarheid te verwijzen.

U kunt AI-systemen ontwerpen die voldoen aan veiligheids- en nalevingsvereisten. Controleontwerp, bewijsverzameling, eigenaarstoewijzing en audit-gereedheid, een controle zonder eigenaar en zonder bewijs faalt wanneer het het meest telt.

Screen 22: Gefeliciteerd! U hebt deze module met succes voltooid.

Module voltooid · Architect · 2 min Gefeliciteerd! U hebt deze module met succes voltooid. Module 3 behandelt de veiligheidsframeworks, risicocategorieën en controleontwerp-beslissingen die verantwoorde AI-architecten vóór en tijdens productie-implementatie toepassen. Een beveiligd pad is niet een filter aan het einde, het is een controle op elke plaats waar schadelijk kan binnenkomen.

0 van 0 checkpoints doorstaan

Claude Platform & Solution Design Modelkeuze, promptarchitectuur, toolontwerp en platform-layer afwegingen.

Enterprise Integration & Production Implementatiepatronen, integatiearchitectuur en productiebetrouwbaarheid.

Verantwoorde AI, Veiligheid & Risico Veiligheidsframeworks, risico-identificatie en governancepraktijken.

U bent hier

Stakeholder Engagement, Lifecycle & Go-to-Market Stakeholder communicatie, levenscyclusbeheer en go-to-market strategie.

Team Enablement en Operational Productivity Team tooling configuratie en operationele ondersteuningspraktijken.

Controleer module Begin opnieuw