santismm-knowledge-mcp 0.2.1
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/LICENSE +21 -0
- package/README.md +62 -0
- package/content/CONVENTIONS.md +77 -0
- package/content/LICENSE +55 -0
- package/content/architectures/ai-workforce.json +280 -0
- package/content/architectures/customer-service-agent.json +292 -0
- package/content/architectures/enterprise-knowledge-assistant.json +292 -0
- package/content/architectures/operations-center.json +280 -0
- package/content/architectures/sales-copilot.json +280 -0
- package/content/governance/agentic-ai-governance-checklist.json +323 -0
- package/content/governance/audit-framework-for-agentic-systems.json +280 -0
- package/content/governance/enterprise-ai-governance-framework.json +277 -0
- package/content/governance/eu-ai-act.json +162 -0
- package/content/governance/human-oversight-and-accountability-policy.json +275 -0
- package/content/governance/iso-42001.json +161 -0
- package/content/governance/mitre-atlas.json +280 -0
- package/content/governance/nist-ai-rmf.json +161 -0
- package/content/governance/owasp-llm-top10.json +301 -0
- package/content/harness/HRN-001-definition-and-overview.es.md +76 -0
- package/content/harness/HRN-001-definition-and-overview.md +125 -0
- package/content/harness/HRN-001-definition-and-overview.pt.md +76 -0
- package/content/harness/HRN-002-a-brief-history-of-harness-engineering.es.md +83 -0
- package/content/harness/HRN-002-a-brief-history-of-harness-engineering.md +113 -0
- package/content/harness/HRN-002-a-brief-history-of-harness-engineering.pt.md +83 -0
- package/content/harness/HRN-003-the-harness-taxonomy.es.md +105 -0
- package/content/harness/HRN-003-the-harness-taxonomy.md +158 -0
- package/content/harness/HRN-003-the-harness-taxonomy.pt.md +105 -0
- package/content/harness/HRN-004-harness-engineering-principles.es.md +91 -0
- package/content/harness/HRN-004-harness-engineering-principles.md +135 -0
- package/content/harness/HRN-004-harness-engineering-principles.pt.md +91 -0
- package/content/harness/HRN-005-memory-in-agentic-systems.es.md +98 -0
- package/content/harness/HRN-005-memory-in-agentic-systems.md +145 -0
- package/content/harness/HRN-005-memory-in-agentic-systems.pt.md +98 -0
- package/content/harness/HRN-006-observability-for-agentic-systems.es.md +97 -0
- package/content/harness/HRN-006-observability-for-agentic-systems.md +139 -0
- package/content/harness/HRN-006-observability-for-agentic-systems.pt.md +97 -0
- package/content/harness/HRN-007-evaluation-of-agentic-systems.es.md +96 -0
- package/content/harness/HRN-007-evaluation-of-agentic-systems.md +145 -0
- package/content/harness/HRN-007-evaluation-of-agentic-systems.pt.md +96 -0
- package/content/harness/HRN-008-governance-within-the-harness.es.md +105 -0
- package/content/harness/HRN-008-governance-within-the-harness.md +146 -0
- package/content/harness/HRN-008-governance-within-the-harness.pt.md +105 -0
- package/content/harness/HRN-009-planning-and-goal-management.es.md +102 -0
- package/content/harness/HRN-009-planning-and-goal-management.md +142 -0
- package/content/harness/HRN-009-planning-and-goal-management.pt.md +102 -0
- package/content/harness/HRN-010-orchestration.es.md +107 -0
- package/content/harness/HRN-010-orchestration.md +149 -0
- package/content/harness/HRN-010-orchestration.pt.md +107 -0
- package/content/harness/HRN-011-security-for-agentic-systems.es.md +107 -0
- package/content/harness/HRN-011-security-for-agentic-systems.md +147 -0
- package/content/harness/HRN-011-security-for-agentic-systems.pt.md +107 -0
- package/content/harness/HRN-012-case-studies-in-harness-engineering.es.md +120 -0
- package/content/harness/HRN-012-case-studies-in-harness-engineering.md +157 -0
- package/content/harness/HRN-012-case-studies-in-harness-engineering.pt.md +120 -0
- package/content/harness/HRN-013-glossary.es.md +109 -0
- package/content/harness/HRN-013-glossary.md +124 -0
- package/content/harness/HRN-013-glossary.pt.md +109 -0
- package/content/harness/HRN-014-bibliography.es.md +89 -0
- package/content/harness/HRN-014-bibliography.md +109 -0
- package/content/harness/HRN-014-bibliography.pt.md +89 -0
- package/content/homeric/episodes/achilles-and-hector.json +139 -0
- package/content/homeric/episodes/aeolus-and-the-winds.json +131 -0
- package/content/homeric/episodes/agamemnons-murder.json +162 -0
- package/content/homeric/episodes/calypso-ogygia.json +157 -0
- package/content/homeric/episodes/catalogue-of-ships.json +177 -0
- package/content/homeric/episodes/cattle-of-the-sun.json +131 -0
- package/content/homeric/episodes/chryse-and-the-plague.json +131 -0
- package/content/homeric/episodes/cicones-at-ismarus.json +131 -0
- package/content/homeric/episodes/circe-on-aeaea.json +131 -0
- package/content/homeric/episodes/cyclops-polyphemus.json +162 -0
- package/content/homeric/episodes/laestrygonians.json +153 -0
- package/content/homeric/episodes/lotus-eaters.json +138 -0
- package/content/homeric/episodes/menelaus-and-proteus.json +130 -0
- package/content/homeric/episodes/nekyia.json +160 -0
- package/content/homeric/episodes/phaeacians-on-scheria.json +129 -0
- package/content/homeric/episodes/priams-ransom.json +131 -0
- package/content/homeric/episodes/return-to-ithaca.json +167 -0
- package/content/homeric/episodes/scylla-and-charybdis.json +131 -0
- package/content/homeric/episodes/suitors-ambush-at-asteris.json +131 -0
- package/content/homeric/episodes/telemachus-at-pylos.json +130 -0
- package/content/homeric/episodes/telemachus-in-sparta.json +130 -0
- package/content/homeric/episodes/the-achaean-camp.json +138 -0
- package/content/homeric/episodes/the-sirens.json +129 -0
- package/content/homeric/episodes/wooden-horse.json +168 -0
- package/content/homeric/places/aeaea.json +129 -0
- package/content/homeric/places/aeolia.json +161 -0
- package/content/homeric/places/asteris.json +120 -0
- package/content/homeric/places/aulis.json +122 -0
- package/content/homeric/places/cape-malea.json +126 -0
- package/content/homeric/places/chryse.json +120 -0
- package/content/homeric/places/dodona.json +129 -0
- package/content/homeric/places/dulichium.json +177 -0
- package/content/homeric/places/egypt.json +125 -0
- package/content/homeric/places/ephyra-acheron.json +127 -0
- package/content/homeric/places/hellespont.json +125 -0
- package/content/homeric/places/house-of-hades.json +91 -0
- package/content/homeric/places/ismarus.json +120 -0
- package/content/homeric/places/ithaca.json +240 -0
- package/content/homeric/places/knossos.json +132 -0
- package/content/homeric/places/laestrygonia.json +168 -0
- package/content/homeric/places/land-of-the-cyclopes.json +169 -0
- package/content/homeric/places/land-of-the-lotus-eaters.json +122 -0
- package/content/homeric/places/mount-ida.json +126 -0
- package/content/homeric/places/mycenae.json +152 -0
- package/content/homeric/places/ogygia.json +125 -0
- package/content/homeric/places/pharos.json +120 -0
- package/content/homeric/places/planctae.json +77 -0
- package/content/homeric/places/pylos.json +188 -0
- package/content/homeric/places/same.json +177 -0
- package/content/homeric/places/scheria.json +129 -0
- package/content/homeric/places/scylla-and-charybdis.json +135 -0
- package/content/homeric/places/sirens.json +127 -0
- package/content/homeric/places/sparta.json +179 -0
- package/content/homeric/places/tenedos.json +129 -0
- package/content/homeric/places/thrinacia.json +116 -0
- package/content/homeric/places/tiryns.json +123 -0
- package/content/homeric/places/troy.json +224 -0
- package/content/homeric/places/zacynthus.json +126 -0
- package/content/homeric/routes/achaean-expedition.json +132 -0
- package/content/homeric/routes/nostoi-of-the-others.json +205 -0
- package/content/homeric/routes/odysseus-nostos.json +307 -0
- package/content/homeric/routes/telemachy.json +134 -0
- package/content/knowledge/agent-memory.json +153 -0
- package/content/knowledge/agentic-ai.json +158 -0
- package/content/knowledge/agentic-evaluation.json +156 -0
- package/content/knowledge/agentic-threat-model.json +287 -0
- package/content/knowledge/ai-agent.json +153 -0
- package/content/knowledge/ai-cyberdefense.json +274 -0
- package/content/knowledge/ai-governance.json +155 -0
- package/content/knowledge/ai-observability.json +156 -0
- package/content/knowledge/context-engineering.json +153 -0
- package/content/knowledge/embeddings.json +153 -0
- package/content/knowledge/enterprise-rag.json +154 -0
- package/content/knowledge/fine-tuning.json +153 -0
- package/content/knowledge/foundation-models.json +154 -0
- package/content/knowledge/guardrails.json +153 -0
- package/content/knowledge/harness-engineering.json +158 -0
- package/content/knowledge/human-in-the-loop.json +153 -0
- package/content/knowledge/mcp-security.json +284 -0
- package/content/knowledge/model-context-protocol.json +154 -0
- package/content/knowledge/multi-agent-architecture.json +153 -0
- package/content/knowledge/prompt-engineering.json +153 -0
- package/content/knowledge/prompt-injection.json +138 -0
- package/content/knowledge/reasoning-models.json +153 -0
- package/content/knowledge/tool-use.json +156 -0
- package/content/library/cognitive-architecture-emergent-ai.md +15 -0
- package/content/library/devready-ep108-ai-customer-experiences.md +14 -0
- package/content/library/how-genai-impact-business.md +12 -0
- package/content/library/lmm-reshaping-industries-2024.md +12 -0
- package/content/library/rethinking-ai-pause.md +12 -0
- package/content/library/rise-of-agentic-ai.md +16 -0
- package/content/library/self-improving-autonomous-ai.md +16 -0
- package/content/library/the-stopwatch-and-the-exam.md +12 -0
- package/content/library/unlock-gpt4-secrets.md +12 -0
- package/content/library/vibe-coding-enterprise.md +15 -0
- package/content/library/video-transformando-negocios-genai.md +14 -0
- package/content/library/video-volando-alto-sky-airlines.md +13 -0
- package/content/matrix/agentic-control-matrix.json +967 -0
- package/content/patterns/attributed-memory.json +237 -0
- package/content/patterns/context-compression.json +304 -0
- package/content/patterns/egress-allowlist.json +310 -0
- package/content/patterns/evaluator-optimizer.json +180 -0
- package/content/patterns/goal-decomposition.json +290 -0
- package/content/patterns/human-approval-gate.json +311 -0
- package/content/patterns/human-escalation.json +288 -0
- package/content/patterns/least-privilege-tooling.json +333 -0
- package/content/patterns/long-term-memory.json +305 -0
- package/content/patterns/orchestrator-workers.json +202 -0
- package/content/patterns/parallelization.json +180 -0
- package/content/patterns/prompt-chaining.json +181 -0
- package/content/patterns/recovery-strategy.json +305 -0
- package/content/patterns/reflection.json +298 -0
- package/content/patterns/routing.json +294 -0
- package/content/patterns/sandboxed-execution.json +311 -0
- package/content/patterns/semantic-caching.json +201 -0
- package/content/patterns/supervisor-agent.json +290 -0
- package/content/patterns/task-prioritization.json +307 -0
- package/dist/content.js +181 -0
- package/dist/index.js +27 -0
- package/dist/shape.js +649 -0
- package/dist/tools.js +652 -0
- package/package.json +47 -0
|
@@ -0,0 +1,280 @@
|
|
|
1
|
+
{
|
|
2
|
+
"id": "GOV-009",
|
|
3
|
+
"slug": "mitre-atlas",
|
|
4
|
+
"category": "framework",
|
|
5
|
+
"updated": "2026-08-22",
|
|
6
|
+
"version": "1.0",
|
|
7
|
+
"evidence": {
|
|
8
|
+
"evidenceLevel": "industry_observation",
|
|
9
|
+
"confidenceLevel": "high",
|
|
10
|
+
"sourceType": [
|
|
11
|
+
"paper",
|
|
12
|
+
"industry_observation"
|
|
13
|
+
]
|
|
14
|
+
},
|
|
15
|
+
"frameworks": [
|
|
16
|
+
"MITRE ATLAS",
|
|
17
|
+
"MITRE ATT&CK",
|
|
18
|
+
"OWASP GenAI Security Project",
|
|
19
|
+
"NIST AI RMF"
|
|
20
|
+
],
|
|
21
|
+
"patterns": [
|
|
22
|
+
"least-privilege-tooling",
|
|
23
|
+
"egress-allowlist",
|
|
24
|
+
"sandboxed-execution"
|
|
25
|
+
],
|
|
26
|
+
"knowledge": [
|
|
27
|
+
"agentic-threat-model",
|
|
28
|
+
"ai-cyberdefense",
|
|
29
|
+
"prompt-injection",
|
|
30
|
+
"mcp-security",
|
|
31
|
+
"ai-observability"
|
|
32
|
+
],
|
|
33
|
+
"references": [
|
|
34
|
+
{
|
|
35
|
+
"title": "MITRE ATLAS — Adversarial Threat Landscape for AI Systems",
|
|
36
|
+
"url": "https://atlas.mitre.org/"
|
|
37
|
+
},
|
|
38
|
+
{
|
|
39
|
+
"title": "OWASP — Top 10 for LLM Applications",
|
|
40
|
+
"url": "https://genai.owasp.org/llm-top-10/"
|
|
41
|
+
},
|
|
42
|
+
{
|
|
43
|
+
"title": "NIST — AI Risk Management Framework (AI RMF 1.0)",
|
|
44
|
+
"url": "https://www.nist.gov/itl/ai-risk-management-framework"
|
|
45
|
+
}
|
|
46
|
+
],
|
|
47
|
+
"related": [
|
|
48
|
+
"owasp-llm-top10",
|
|
49
|
+
"nist-ai-rmf",
|
|
50
|
+
"audit-framework-for-agentic-systems",
|
|
51
|
+
"agentic-ai-governance-checklist"
|
|
52
|
+
],
|
|
53
|
+
"locales": {
|
|
54
|
+
"en": {
|
|
55
|
+
"name": "MITRE ATLAS",
|
|
56
|
+
"summary": "MITRE ATLAS is the adversary's side of the map. Where OWASP names the vulnerability classes in your application, ATLAS catalogues the tactics and techniques attackers actually use against AI-enabled systems — reconnaissance of a model, gaining access to it, staging an attack, evading defences, exfiltrating data — organised the way MITRE ATT&CK organises conventional intrusions, and grounded in documented case studies rather than hypotheses.",
|
|
57
|
+
"definition": "MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) is a publicly available knowledge base of adversary tactics, techniques and case studies observed against AI-enabled systems, structured after MITRE ATT&CK so that AI-specific attacks can be described in the same terms as the rest of an organisation's threat intelligence.",
|
|
58
|
+
"scope": "Any organisation that builds, deploys or defends AI-enabled systems, and any security team that already speaks ATT&CK. It is a knowledge base, not a standard: nothing certifies against it, and it prescribes no controls — it describes what adversaries do so defenders can decide what to detect and prevent.",
|
|
59
|
+
"keyPoints": [
|
|
60
|
+
"Structured as tactics (the adversary's goal) and techniques (how it is achieved), deliberately mirroring MITRE ATT&CK so AI attacks slot into existing threat models rather than sitting beside them.",
|
|
61
|
+
"It spans the whole intrusion arc — reconnaissance, access to the model, execution, persistence, defence evasion, discovery, collection, exfiltration, impact — with AI-specific stages such as staging an attack against a model.",
|
|
62
|
+
"It is evidence-led: entries are grounded in documented incidents and red-team exercises, which is what separates it from a list of things that could theoretically go wrong.",
|
|
63
|
+
"It complements OWASP rather than competing with it. OWASP classifies weaknesses in your design; ATLAS describes the adversary behaviour that exploits them.",
|
|
64
|
+
"Its practical value is detection and red-teaming: a technique is a thing you can attempt against your own system and a thing you can look for in your logs.",
|
|
65
|
+
"The matrix is maintained and extended as new attacks are documented, so it is a living reference and not a fixed checklist."
|
|
66
|
+
],
|
|
67
|
+
"controls": [
|
|
68
|
+
{
|
|
69
|
+
"control": "Map your agent stack onto the matrix",
|
|
70
|
+
"note": "Walk the tactics against your own architecture and mark which techniques are reachable. Reachability, not plausibility, is what makes a technique worth defending against."
|
|
71
|
+
},
|
|
72
|
+
{
|
|
73
|
+
"control": "Turn reachable techniques into detections",
|
|
74
|
+
"note": "For each one, name the signal that would show it in your telemetry. A technique with no corresponding signal is one you have decided not to notice."
|
|
75
|
+
},
|
|
76
|
+
{
|
|
77
|
+
"control": "Use it as the red-team backlog",
|
|
78
|
+
"note": "Techniques are testable by construction. Run them against your own system and treat 'we could not reproduce it' as a result worth recording, not as an absence of work."
|
|
79
|
+
},
|
|
80
|
+
{
|
|
81
|
+
"control": "Speak ATT&CK where the organisation already does",
|
|
82
|
+
"note": "Report AI findings in ATLAS terms so they enter the same intelligence, triage and response processes as everything else. Novel vocabulary is how AI risk ends up owned by nobody."
|
|
83
|
+
},
|
|
84
|
+
{
|
|
85
|
+
"control": "Read the case studies, not only the matrix",
|
|
86
|
+
"note": "The case studies carry the operational detail — how access was obtained, what the adversary did next — which is the part that transfers to your own environment."
|
|
87
|
+
},
|
|
88
|
+
{
|
|
89
|
+
"control": "Feed it back into the threat model",
|
|
90
|
+
"note": "ATLAS is the external input to an agentic threat model; the threat model is where its techniques become surfaces you own, with controls and owners attached."
|
|
91
|
+
}
|
|
92
|
+
],
|
|
93
|
+
"checklist": [
|
|
94
|
+
"Identify which ATLAS tactics are reachable in your architecture at all.",
|
|
95
|
+
"For each reachable technique, record the control that bounds it and the signal that detects it.",
|
|
96
|
+
"Where there is no detection, say so explicitly rather than leaving the row blank.",
|
|
97
|
+
"Schedule red-team exercises drawn from the matrix, and see each attempt fail or succeed before claiming coverage.",
|
|
98
|
+
"Report findings using ATLAS identifiers so they join the organisation's existing intelligence flow.",
|
|
99
|
+
"Review the matrix periodically, since new techniques are documented as they are observed.",
|
|
100
|
+
"Cross-reference with the OWASP LLM Top 10 so weaknesses and adversary behaviour are mapped to each other, not tracked separately."
|
|
101
|
+
],
|
|
102
|
+
"pitfalls": [
|
|
103
|
+
"Treating it as a compliance checklist. Nothing certifies against ATLAS, and 'we reviewed the matrix' is not a control.",
|
|
104
|
+
"Mapping every technique regardless of reachability, which produces a large document and no priorities.",
|
|
105
|
+
"Keeping AI threat intelligence in a separate process from the organisation's existing one — the exact outcome ATT&CK alignment exists to prevent.",
|
|
106
|
+
"Reading the matrix and skipping the case studies, which is where the transferable operational detail lives.",
|
|
107
|
+
"Assuming coverage without testing. A technique you have never attempted against your own system is a technique you have an opinion about."
|
|
108
|
+
],
|
|
109
|
+
"examples": [
|
|
110
|
+
"A team maps its retrieval agent onto ATLAS and finds that model access is trivial (the endpoint is public), staging is cheap (any wiki editor can plant content) and exfiltration has no control (egress is unrestricted). Three techniques, one of which they were already worrying about.",
|
|
111
|
+
"A security organisation that already runs ATT&CK-based detection engineering adds ATLAS techniques to the same backlog, so AI-specific detections are built, reviewed and on-call'd by the team that does that work.",
|
|
112
|
+
"A red team uses the matrix as its target list for an agent assessment, and reports back in ATLAS identifiers — which lets the finding be triaged by people who have never worked on an agent."
|
|
113
|
+
],
|
|
114
|
+
"faqs": [
|
|
115
|
+
{
|
|
116
|
+
"q": "Is ATLAS a replacement for ATT&CK?",
|
|
117
|
+
"a": "No, it is a companion. ATT&CK covers conventional adversary behaviour; ATLAS covers the AI-specific stages, deliberately structured the same way so an attack that starts with a phishing email and ends at a model is describable end to end."
|
|
118
|
+
},
|
|
119
|
+
{
|
|
120
|
+
"q": "Do I need ATLAS if I already follow the OWASP LLM Top 10?",
|
|
121
|
+
"a": "They serve different purposes and the pairing is the point. OWASP tells you what class of weakness you have; ATLAS tells you what an adversary does with it, which is what detection and red-teaming actually need."
|
|
122
|
+
},
|
|
123
|
+
{
|
|
124
|
+
"q": "Where does it fit for a small team?",
|
|
125
|
+
"a": "As a red-team backlog first. Even without a detection programme, the matrix gives a prioritised list of attacks to attempt against your own system — and attempting them is the cheapest way to find out which of your controls exist only on paper."
|
|
126
|
+
}
|
|
127
|
+
]
|
|
128
|
+
},
|
|
129
|
+
"es": {
|
|
130
|
+
"name": "MITRE ATLAS",
|
|
131
|
+
"summary": "MITRE ATLAS es el mapa visto desde el lado del adversario. Donde OWASP nombra las clases de vulnerabilidad de tu aplicación, ATLAS cataloga las tácticas y técnicas que los atacantes usan de verdad contra sistemas con IA —reconocer un modelo, ganar acceso a él, preparar el ataque, evadir defensas, exfiltrar datos—, organizadas como MITRE ATT&CK organiza las intrusiones convencionales y ancladas en casos documentados, no en hipótesis.",
|
|
132
|
+
"definition": "MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) es una base de conocimiento pública de tácticas, técnicas y casos de estudio de adversarios observados contra sistemas con IA, estructurada siguiendo a MITRE ATT&CK para que los ataques específicos de IA se puedan describir en los mismos términos que el resto de la inteligencia de amenazas de una organización.",
|
|
133
|
+
"scope": "Cualquier organización que construya, despliegue o defienda sistemas con IA, y cualquier equipo de seguridad que ya hable ATT&CK. Es una base de conocimiento, no una norma: nada certifica contra ella y no prescribe controles; describe lo que hacen los adversarios para que quien defiende decida qué detectar y qué prevenir.",
|
|
134
|
+
"keyPoints": [
|
|
135
|
+
"Estructurada en tácticas (el objetivo del adversario) y técnicas (cómo se logra), reflejando deliberadamente a MITRE ATT&CK para que los ataques de IA encajen en los modelos de amenaza existentes en lugar de vivir al lado.",
|
|
136
|
+
"Cubre todo el arco de la intrusión —reconocimiento, acceso al modelo, ejecución, persistencia, evasión de defensas, descubrimiento, recolección, exfiltración, impacto— con etapas específicas de IA como la preparación de un ataque contra un modelo.",
|
|
137
|
+
"Está guiada por evidencia: las entradas se apoyan en incidentes documentados y ejercicios de red team, que es lo que la separa de una lista de cosas que teóricamente podrían salir mal.",
|
|
138
|
+
"Complementa a OWASP en lugar de competir con ella. OWASP clasifica debilidades de tu diseño; ATLAS describe el comportamiento adversario que las explota.",
|
|
139
|
+
"Su valor práctico está en la detección y el red team: una técnica es algo que puedes intentar contra tu propio sistema y algo que puedes buscar en tus logs.",
|
|
140
|
+
"La matriz se mantiene y amplía conforme se documentan ataques nuevos, así que es una referencia viva y no una lista de comprobación fija."
|
|
141
|
+
],
|
|
142
|
+
"controls": [
|
|
143
|
+
{
|
|
144
|
+
"control": "Mapea tu pila agéntica sobre la matriz",
|
|
145
|
+
"note": "Recorre las tácticas frente a tu arquitectura y marca qué técnicas son alcanzables. Lo que hace que merezca la pena defender una técnica es su alcanzabilidad, no su plausibilidad."
|
|
146
|
+
},
|
|
147
|
+
{
|
|
148
|
+
"control": "Convierte las técnicas alcanzables en detecciones",
|
|
149
|
+
"note": "Para cada una, nombra la señal que la mostraría en tu telemetría. Una técnica sin señal correspondiente es una que has decidido no ver."
|
|
150
|
+
},
|
|
151
|
+
{
|
|
152
|
+
"control": "Úsala como backlog del red team",
|
|
153
|
+
"note": "Las técnicas son comprobables por construcción. Ejecútalas contra tu propio sistema y trata «no pudimos reproducirlo» como un resultado que merece registrarse, no como ausencia de trabajo."
|
|
154
|
+
},
|
|
155
|
+
{
|
|
156
|
+
"control": "Habla ATT&CK donde la organización ya lo habla",
|
|
157
|
+
"note": "Reporta hallazgos de IA en términos de ATLAS para que entren en los mismos procesos de inteligencia, triaje y respuesta que todo lo demás. El vocabulario nuevo es la vía por la que el riesgo de IA acaba sin dueño."
|
|
158
|
+
},
|
|
159
|
+
{
|
|
160
|
+
"control": "Lee los casos de estudio, no solo la matriz",
|
|
161
|
+
"note": "Los casos llevan el detalle operativo —cómo se obtuvo el acceso, qué hizo el adversario después—, que es la parte que se traslada a tu propio entorno."
|
|
162
|
+
},
|
|
163
|
+
{
|
|
164
|
+
"control": "Devuélvela al modelo de amenazas",
|
|
165
|
+
"note": "ATLAS es la entrada externa a un modelo de amenazas agéntico; el modelo es donde sus técnicas se convierten en superficies tuyas, con controles y responsables asociados."
|
|
166
|
+
}
|
|
167
|
+
],
|
|
168
|
+
"checklist": [
|
|
169
|
+
"Identifica qué tácticas de ATLAS son siquiera alcanzables en tu arquitectura.",
|
|
170
|
+
"Para cada técnica alcanzable, registra el control que la acota y la señal que la detecta.",
|
|
171
|
+
"Donde no haya detección, dilo explícitamente en lugar de dejar la fila en blanco.",
|
|
172
|
+
"Programa ejercicios de red team sacados de la matriz y ve fallar o triunfar cada intento antes de afirmar cobertura.",
|
|
173
|
+
"Reporta los hallazgos con identificadores de ATLAS para que entren en el flujo de inteligencia existente de la organización.",
|
|
174
|
+
"Revisa la matriz periódicamente, porque se documentan técnicas nuevas conforme se observan.",
|
|
175
|
+
"Cruza con el OWASP LLM Top 10 para que debilidades y comportamiento adversario queden mapeados entre sí y no en registros separados."
|
|
176
|
+
],
|
|
177
|
+
"pitfalls": [
|
|
178
|
+
"Tratarla como lista de cumplimiento. Nada certifica contra ATLAS, y «revisamos la matriz» no es un control.",
|
|
179
|
+
"Mapear todas las técnicas sin importar su alcanzabilidad, lo que produce un documento grande y ninguna prioridad.",
|
|
180
|
+
"Mantener la inteligencia de amenazas de IA en un proceso aparte del que ya tiene la organización: justo el resultado que la alineación con ATT&CK existe para evitar.",
|
|
181
|
+
"Leer la matriz y saltarse los casos de estudio, que es donde vive el detalle operativo trasladable.",
|
|
182
|
+
"Suponer cobertura sin probar. Una técnica que nunca has intentado contra tu propio sistema es una técnica sobre la que tienes una opinión."
|
|
183
|
+
],
|
|
184
|
+
"examples": [
|
|
185
|
+
"Un equipo mapea su agente de recuperación sobre ATLAS y descubre que el acceso al modelo es trivial (el endpoint es público), la preparación es barata (cualquier editor de la wiki puede plantar contenido) y la exfiltración no tiene control (la salida no está restringida). Tres técnicas, y solo una les preocupaba ya.",
|
|
186
|
+
"Una organización de seguridad que ya hace ingeniería de detección basada en ATT&CK añade técnicas de ATLAS al mismo backlog, de modo que las detecciones específicas de IA las construye, revisa y guardia el equipo que hace ese trabajo.",
|
|
187
|
+
"Un red team usa la matriz como lista de objetivos para evaluar un agente y reporta con identificadores de ATLAS, lo que permite triar el hallazgo a gente que nunca ha trabajado con agentes."
|
|
188
|
+
],
|
|
189
|
+
"faqs": [
|
|
190
|
+
{
|
|
191
|
+
"q": "¿ATLAS sustituye a ATT&CK?",
|
|
192
|
+
"a": "No, es su compañera. ATT&CK cubre el comportamiento adversario convencional; ATLAS cubre las etapas específicas de IA, estructuradas igual a propósito para que un ataque que empieza con un correo de phishing y termina en un modelo se pueda describir de punta a punta."
|
|
193
|
+
},
|
|
194
|
+
{
|
|
195
|
+
"q": "¿Necesito ATLAS si ya sigo el OWASP LLM Top 10?",
|
|
196
|
+
"a": "Sirven a propósitos distintos y la combinación es justo el punto. OWASP te dice qué clase de debilidad tienes; ATLAS te dice qué hace un adversario con ella, que es lo que de verdad necesitan la detección y el red team."
|
|
197
|
+
},
|
|
198
|
+
{
|
|
199
|
+
"q": "¿Por dónde encaja para un equipo pequeño?",
|
|
200
|
+
"a": "Primero como backlog de red team. Incluso sin un programa de detección, la matriz da una lista priorizada de ataques que intentar contra tu propio sistema, e intentarlos es la forma más barata de descubrir cuáles de tus controles solo existen sobre el papel."
|
|
201
|
+
}
|
|
202
|
+
]
|
|
203
|
+
},
|
|
204
|
+
"pt": {
|
|
205
|
+
"name": "MITRE ATLAS",
|
|
206
|
+
"summary": "O MITRE ATLAS é o mapa visto do lado do adversário. Onde o OWASP nomeia as classes de vulnerabilidade da sua aplicação, o ATLAS cataloga as táticas e técnicas que atacantes de fato usam contra sistemas com IA — reconhecer um modelo, obter acesso a ele, preparar o ataque, evadir defesas, exfiltrar dados —, organizadas como o MITRE ATT&CK organiza as intrusões convencionais e ancoradas em casos documentados, não em hipóteses.",
|
|
207
|
+
"definition": "O MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) é uma base de conhecimento pública de táticas, técnicas e estudos de caso de adversários observados contra sistemas com IA, estruturada segundo o MITRE ATT&CK para que ataques específicos de IA possam ser descritos nos mesmos termos que o restante da inteligência de ameaças de uma organização.",
|
|
208
|
+
"scope": "Qualquer organização que construa, implante ou defenda sistemas com IA, e qualquer time de segurança que já fale ATT&CK. É uma base de conhecimento, não uma norma: nada certifica contra ela e ela não prescreve controles; descreve o que os adversários fazem para que quem defende decida o que detectar e o que prevenir.",
|
|
209
|
+
"keyPoints": [
|
|
210
|
+
"Estruturado em táticas (o objetivo do adversário) e técnicas (como se alcança), espelhando deliberadamente o MITRE ATT&CK para que os ataques de IA encaixem nos modelos de ameaça existentes em vez de ficarem ao lado deles.",
|
|
211
|
+
"Cobre todo o arco da intrusão — reconhecimento, acesso ao modelo, execução, persistência, evasão de defesas, descoberta, coleta, exfiltração, impacto — com estágios específicos de IA, como a preparação de um ataque contra um modelo.",
|
|
212
|
+
"É guiado por evidência: as entradas se apoiam em incidentes documentados e exercícios de red team, o que o separa de uma lista de coisas que teoricamente poderiam dar errado.",
|
|
213
|
+
"Complementa o OWASP em vez de competir com ele. O OWASP classifica fragilidades do seu design; o ATLAS descreve o comportamento adversário que as explora.",
|
|
214
|
+
"Seu valor prático está na detecção e no red team: uma técnica é algo que você pode tentar contra o próprio sistema e algo que pode procurar nos seus logs.",
|
|
215
|
+
"A matriz é mantida e ampliada conforme novos ataques são documentados, então é uma referência viva e não uma lista de verificação fixa."
|
|
216
|
+
],
|
|
217
|
+
"controls": [
|
|
218
|
+
{
|
|
219
|
+
"control": "Mapeie a sua pilha agêntica sobre a matriz",
|
|
220
|
+
"note": "Percorra as táticas diante da sua arquitetura e marque quais técnicas são alcançáveis. O que torna uma técnica digna de defesa é a alcançabilidade, não a plausibilidade."
|
|
221
|
+
},
|
|
222
|
+
{
|
|
223
|
+
"control": "Transforme técnicas alcançáveis em detecções",
|
|
224
|
+
"note": "Para cada uma, nomeie o sinal que a mostraria na sua telemetria. Uma técnica sem sinal correspondente é uma que você decidiu não enxergar."
|
|
225
|
+
},
|
|
226
|
+
{
|
|
227
|
+
"control": "Use-a como backlog do red team",
|
|
228
|
+
"note": "As técnicas são testáveis por construção. Execute-as contra o seu próprio sistema e trate «não conseguimos reproduzir» como um resultado que vale registrar, não como ausência de trabalho."
|
|
229
|
+
},
|
|
230
|
+
{
|
|
231
|
+
"control": "Fale ATT&CK onde a organização já fala",
|
|
232
|
+
"note": "Relate achados de IA em termos de ATLAS para que entrem nos mesmos processos de inteligência, triagem e resposta que todo o resto. Vocabulário novo é como o risco de IA acaba sem dono."
|
|
233
|
+
},
|
|
234
|
+
{
|
|
235
|
+
"control": "Leia os estudos de caso, não só a matriz",
|
|
236
|
+
"note": "Os casos carregam o detalhe operacional — como o acesso foi obtido, o que o adversário fez em seguida —, que é a parte que se transfere para o seu ambiente."
|
|
237
|
+
},
|
|
238
|
+
{
|
|
239
|
+
"control": "Devolva ao modelo de ameaças",
|
|
240
|
+
"note": "O ATLAS é a entrada externa de um modelo de ameaças agêntico; o modelo é onde as técnicas dele viram superfícies suas, com controles e responsáveis associados."
|
|
241
|
+
}
|
|
242
|
+
],
|
|
243
|
+
"checklist": [
|
|
244
|
+
"Identifique quais táticas do ATLAS são sequer alcançáveis na sua arquitetura.",
|
|
245
|
+
"Para cada técnica alcançável, registre o controle que a limita e o sinal que a detecta.",
|
|
246
|
+
"Onde não houver detecção, diga isso explicitamente em vez de deixar a linha em branco.",
|
|
247
|
+
"Agende exercícios de red team tirados da matriz e veja cada tentativa falhar ou ter êxito antes de alegar cobertura.",
|
|
248
|
+
"Relate os achados com identificadores do ATLAS para que entrem no fluxo de inteligência já existente.",
|
|
249
|
+
"Revise a matriz periodicamente, pois novas técnicas são documentadas conforme observadas.",
|
|
250
|
+
"Cruze com o OWASP Top 10 para LLM para que fragilidades e comportamento adversário fiquem mapeados entre si, e não em registros separados."
|
|
251
|
+
],
|
|
252
|
+
"pitfalls": [
|
|
253
|
+
"Tratá-lo como lista de conformidade. Nada certifica contra o ATLAS, e «revisamos a matriz» não é um controle.",
|
|
254
|
+
"Mapear todas as técnicas independentemente da alcançabilidade, o que produz um documento grande e nenhuma prioridade.",
|
|
255
|
+
"Manter a inteligência de ameaças de IA num processo separado do que a organização já tem — exatamente o resultado que o alinhamento com ATT&CK existe para evitar.",
|
|
256
|
+
"Ler a matriz e pular os estudos de caso, que é onde mora o detalhe operacional transferível.",
|
|
257
|
+
"Supor cobertura sem testar. Uma técnica que você nunca tentou contra o próprio sistema é uma técnica sobre a qual você tem uma opinião."
|
|
258
|
+
],
|
|
259
|
+
"examples": [
|
|
260
|
+
"Um time mapeia seu agente de recuperação no ATLAS e descobre que o acesso ao modelo é trivial (o endpoint é público), a preparação é barata (qualquer editor da wiki pode plantar conteúdo) e a exfiltração não tem controle (a saída é irrestrita). Três técnicas, e apenas uma já preocupava.",
|
|
261
|
+
"Uma organização de segurança que já faz engenharia de detecção baseada em ATT&CK acrescenta técnicas do ATLAS ao mesmo backlog, de modo que as detecções específicas de IA são construídas, revisadas e plantonadas pelo time que faz esse trabalho.",
|
|
262
|
+
"Um red team usa a matriz como lista de alvos para avaliar um agente e relata com identificadores do ATLAS, o que permite triar o achado por pessoas que nunca trabalharam com agentes."
|
|
263
|
+
],
|
|
264
|
+
"faqs": [
|
|
265
|
+
{
|
|
266
|
+
"q": "O ATLAS substitui o ATT&CK?",
|
|
267
|
+
"a": "Não, é um companheiro. O ATT&CK cobre o comportamento adversário convencional; o ATLAS cobre os estágios específicos de IA, estruturados da mesma forma de propósito para que um ataque que começa com um e-mail de phishing e termina em um modelo seja descritível de ponta a ponta."
|
|
268
|
+
},
|
|
269
|
+
{
|
|
270
|
+
"q": "Preciso do ATLAS se já sigo o OWASP Top 10 para LLM?",
|
|
271
|
+
"a": "Eles servem a propósitos diferentes, e a combinação é justamente o ponto. O OWASP diz que classe de fragilidade você tem; o ATLAS diz o que um adversário faz com ela, que é o que detecção e red team de fato precisam."
|
|
272
|
+
},
|
|
273
|
+
{
|
|
274
|
+
"q": "Onde ele encaixa para um time pequeno?",
|
|
275
|
+
"a": "Primeiro como backlog de red team. Mesmo sem um programa de detecção, a matriz dá uma lista priorizada de ataques a tentar contra o próprio sistema — e tentá-los é a forma mais barata de descobrir quais dos seus controles só existem no papel."
|
|
276
|
+
}
|
|
277
|
+
]
|
|
278
|
+
}
|
|
279
|
+
}
|
|
280
|
+
}
|
|
@@ -0,0 +1,161 @@
|
|
|
1
|
+
{
|
|
2
|
+
"id": "GOV-003",
|
|
3
|
+
"slug": "nist-ai-rmf",
|
|
4
|
+
"category": "framework",
|
|
5
|
+
"updated": "2026-06-21",
|
|
6
|
+
"version": "1.0",
|
|
7
|
+
"featured": true,
|
|
8
|
+
"evidence": {
|
|
9
|
+
"evidenceLevel": "industry_observation",
|
|
10
|
+
"confidenceLevel": "high",
|
|
11
|
+
"sourceType": ["paper", "industry_observation"]
|
|
12
|
+
},
|
|
13
|
+
"frameworks": ["NIST AI RMF"],
|
|
14
|
+
"patterns": ["human-approval-gate", "evaluator-optimizer"],
|
|
15
|
+
"knowledge": ["ai-governance", "agentic-evaluation", "ai-observability", "guardrails"],
|
|
16
|
+
"references": [
|
|
17
|
+
{ "title": "NIST — AI Risk Management Framework (AI RMF 1.0)", "url": "https://www.nist.gov/itl/ai-risk-management-framework" },
|
|
18
|
+
{ "title": "NIST AI 600-1 — Generative AI Profile", "url": "https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-generative-artificial-intelligence" }
|
|
19
|
+
],
|
|
20
|
+
"related": ["eu-ai-act", "iso-42001", "agentic-ai-governance-checklist", "owasp-llm-top10", "mitre-atlas"],
|
|
21
|
+
"locales": {
|
|
22
|
+
"en": {
|
|
23
|
+
"name": "NIST AI Risk Management Framework",
|
|
24
|
+
"summary": "The NIST AI RMF 1.0 is a voluntary, widely-adopted framework for managing AI risk across the lifecycle. It is organized around four functions — Govern, Map, Measure and Manage — and a set of characteristics of trustworthy AI (valid and reliable, safe, secure and resilient, accountable and transparent, explainable, privacy-enhanced, and fair with harmful bias managed). A companion Generative AI Profile adapts it to GenAI risks. Unlike the EU AI Act it is not law, but it is a common backbone for operational AI governance.",
|
|
25
|
+
"definition": "The NIST AI Risk Management Framework is a voluntary framework that helps organizations govern, map, measure and manage the risks of AI systems while pursuing the characteristics of trustworthy AI.",
|
|
26
|
+
"scope": "Any organization designing, developing, deploying or using AI, in any sector. It is voluntary and outcome-focused, designed to be tailored to context and used alongside standards and regulation.",
|
|
27
|
+
"keyPoints": [
|
|
28
|
+
"Four core functions: Govern (culture & accountability), Map (context & risks), Measure (assess & track), Manage (prioritize & respond).",
|
|
29
|
+
"Govern is cross-cutting — it underpins the other three.",
|
|
30
|
+
"Defines characteristics of trustworthy AI to aim for, not just risks to avoid.",
|
|
31
|
+
"A companion Generative AI Profile (NIST AI 600-1) addresses GenAI-specific risks.",
|
|
32
|
+
"Voluntary and flexible — meant to be tailored, not certified against.",
|
|
33
|
+
"Pairs well with ISO/IEC 42001 (management system) and the EU AI Act (law)."
|
|
34
|
+
],
|
|
35
|
+
"controls": [
|
|
36
|
+
{ "control": "Govern", "note": "Establish the policies, accountability, culture and roles that make risk management real — the foundation the other functions stand on." },
|
|
37
|
+
{ "control": "Map", "note": "Establish context: intended use, stakeholders, and the risks and impacts of the AI system before building." },
|
|
38
|
+
{ "control": "Measure", "note": "Use quantitative and qualitative methods to assess, benchmark and monitor risk and trustworthiness — you can't manage what you don't measure." },
|
|
39
|
+
{ "control": "Manage", "note": "Prioritize, respond to and track risks over time, including incident response and decommissioning." },
|
|
40
|
+
{ "control": "Trustworthiness characteristics", "note": "Steer toward valid, safe, secure, accountable, explainable, privacy-enhanced and fair outcomes as explicit design targets." }
|
|
41
|
+
],
|
|
42
|
+
"checklist": [
|
|
43
|
+
"Stand up the Govern function: policy, accountability and roles.",
|
|
44
|
+
"Map each system's context, intended use, stakeholders and risks.",
|
|
45
|
+
"Define metrics and Measure validity, safety, security, bias and robustness.",
|
|
46
|
+
"Manage: prioritize risks, plan responses and track them over time.",
|
|
47
|
+
"Apply the Generative AI Profile for GenAI systems.",
|
|
48
|
+
"Set incident response and monitoring for deployed systems.",
|
|
49
|
+
"Map the framework to your obligations under ISO 42001 and the EU AI Act."
|
|
50
|
+
],
|
|
51
|
+
"pitfalls": [
|
|
52
|
+
"Doing Map and Measure but neglecting Govern, so nothing is accountable.",
|
|
53
|
+
"Measuring what's easy instead of what matters for trustworthiness.",
|
|
54
|
+
"Treating it as a checklist rather than a continuous risk practice.",
|
|
55
|
+
"Ignoring the Generative AI Profile for LLM and agentic systems."
|
|
56
|
+
],
|
|
57
|
+
"examples": [
|
|
58
|
+
"A team using Map to document an agent's intended use and stakeholders before building.",
|
|
59
|
+
"A Measure step benchmarking a model for bias and robustness against an eval set.",
|
|
60
|
+
"A Manage process with incident response for a deployed GenAI assistant."
|
|
61
|
+
],
|
|
62
|
+
"faqs": [
|
|
63
|
+
{ "q": "Is the NIST AI RMF mandatory?", "a": "No. It is a voluntary framework. But it is widely adopted as a common language and backbone for operational AI risk management, and often referenced in policy and procurement." },
|
|
64
|
+
{ "q": "What are the four functions?", "a": "Govern, Map, Measure and Manage. Govern is cross-cutting and supports the other three, which run across the AI lifecycle." },
|
|
65
|
+
{ "q": "How does it handle generative AI?", "a": "Through the companion Generative AI Profile (NIST AI 600-1), which identifies GenAI-specific risks and suggested actions mapped to the four functions." }
|
|
66
|
+
]
|
|
67
|
+
},
|
|
68
|
+
"es": {
|
|
69
|
+
"name": "Marco de Gestión de Riesgos de IA del NIST",
|
|
70
|
+
"summary": "El NIST AI RMF 1.0 es un marco voluntario y ampliamente adoptado para gestionar el riesgo de la IA a lo largo de su ciclo de vida. Se organiza en torno a cuatro funciones —Gobernar, Mapear, Medir y Gestionar— y un conjunto de características de IA confiable (válida y fiable, segura, resistente, responsable y transparente, explicable, con privacidad reforzada y justa con el sesgo dañino gestionado). Un Perfil de IA Generativa lo adapta a los riesgos de la GenAI. A diferencia del EU AI Act no es ley, pero es una columna vertebral común para la gobernanza operativa de la IA.",
|
|
71
|
+
"definition": "El Marco de Gestión de Riesgos de IA del NIST es un marco voluntario que ayuda a las organizaciones a gobernar, mapear, medir y gestionar los riesgos de los sistemas de IA mientras persiguen las características de la IA confiable.",
|
|
72
|
+
"scope": "Cualquier organización que diseñe, desarrolle, despliegue o use IA, en cualquier sector. Es voluntario y orientado a resultados, pensado para adaptarse al contexto y usarse junto a normas y regulación.",
|
|
73
|
+
"keyPoints": [
|
|
74
|
+
"Cuatro funciones centrales: Gobernar (cultura y rendición de cuentas), Mapear (contexto y riesgos), Medir (evaluar y seguir), Gestionar (priorizar y responder).",
|
|
75
|
+
"Gobernar es transversal: sustenta a las otras tres.",
|
|
76
|
+
"Define características de IA confiable a perseguir, no solo riesgos a evitar.",
|
|
77
|
+
"Un Perfil de IA Generativa (NIST AI 600-1) aborda los riesgos específicos de la GenAI.",
|
|
78
|
+
"Voluntario y flexible: pensado para adaptarse, no para certificarse.",
|
|
79
|
+
"Encaja bien con ISO/IEC 42001 (sistema de gestión) y el EU AI Act (ley)."
|
|
80
|
+
],
|
|
81
|
+
"controls": [
|
|
82
|
+
{ "control": "Gobernar", "note": "Establece las políticas, la rendición de cuentas, la cultura y los roles que hacen real la gestión de riesgos: la base sobre la que se apoyan las demás funciones." },
|
|
83
|
+
{ "control": "Mapear", "note": "Establece el contexto: uso previsto, partes interesadas, y los riesgos e impactos del sistema de IA antes de construir." },
|
|
84
|
+
{ "control": "Medir", "note": "Usa métodos cuantitativos y cualitativos para evaluar, comparar y monitorizar el riesgo y la confiabilidad: no puedes gestionar lo que no mides." },
|
|
85
|
+
{ "control": "Gestionar", "note": "Prioriza, responde y haz seguimiento de los riesgos en el tiempo, incluyendo respuesta a incidentes y retirada." },
|
|
86
|
+
{ "control": "Características de confiabilidad", "note": "Dirige hacia resultados válidos, seguros, responsables, explicables, con privacidad reforzada y justos como objetivos de diseño explícitos." }
|
|
87
|
+
],
|
|
88
|
+
"checklist": [
|
|
89
|
+
"Pon en marcha la función Gobernar: política, rendición de cuentas y roles.",
|
|
90
|
+
"Mapea el contexto, el uso previsto, las partes interesadas y los riesgos de cada sistema.",
|
|
91
|
+
"Define métricas y Mide validez, seguridad, sesgo y robustez.",
|
|
92
|
+
"Gestiona: prioriza riesgos, planifica respuestas y haz seguimiento en el tiempo.",
|
|
93
|
+
"Aplica el Perfil de IA Generativa para los sistemas de GenAI.",
|
|
94
|
+
"Establece respuesta a incidentes y monitorización para los sistemas desplegados.",
|
|
95
|
+
"Mapea el marco a tus obligaciones bajo ISO 42001 y el EU AI Act."
|
|
96
|
+
],
|
|
97
|
+
"pitfalls": [
|
|
98
|
+
"Hacer Mapear y Medir pero descuidar Gobernar, de modo que nada es responsable.",
|
|
99
|
+
"Medir lo fácil en vez de lo que importa para la confiabilidad.",
|
|
100
|
+
"Tratarlo como una lista de verificación en vez de una práctica continua de riesgo.",
|
|
101
|
+
"Ignorar el Perfil de IA Generativa para sistemas LLM y agénticos."
|
|
102
|
+
],
|
|
103
|
+
"examples": [
|
|
104
|
+
"Un equipo que usa Mapear para documentar el uso previsto y las partes interesadas de un agente antes de construir.",
|
|
105
|
+
"Un paso de Medir que compara un modelo en sesgo y robustez frente a un conjunto de evaluación.",
|
|
106
|
+
"Un proceso de Gestionar con respuesta a incidentes para un asistente de GenAI desplegado."
|
|
107
|
+
],
|
|
108
|
+
"faqs": [
|
|
109
|
+
{ "q": "¿El NIST AI RMF es obligatorio?", "a": "No. Es un marco voluntario. Pero está ampliamente adoptado como lenguaje común y columna vertebral para la gestión operativa del riesgo de IA, y se referencia a menudo en políticas y compras." },
|
|
110
|
+
{ "q": "¿Cuáles son las cuatro funciones?", "a": "Gobernar, Mapear, Medir y Gestionar. Gobernar es transversal y sustenta a las otras tres, que recorren el ciclo de vida de la IA." },
|
|
111
|
+
{ "q": "¿Cómo aborda la IA generativa?", "a": "Mediante el Perfil de IA Generativa complementario (NIST AI 600-1), que identifica riesgos específicos de la GenAI y acciones sugeridas mapeadas a las cuatro funciones." }
|
|
112
|
+
]
|
|
113
|
+
},
|
|
114
|
+
"pt": {
|
|
115
|
+
"name": "Framework de Gestão de Riscos de IA do NIST",
|
|
116
|
+
"summary": "O NIST AI RMF 1.0 é um framework voluntário e amplamente adotado para gerir o risco da IA ao longo do seu ciclo de vida. Organiza-se em torno de quatro funções —Governar, Mapear, Medir e Gerir— e um conjunto de características de IA confiável (válida e confiável, segura, resiliente, responsável e transparente, explicável, com privacidade reforçada e justa com o viés prejudicial gerido). Um Perfil de IA Generativa o adapta aos riscos da GenAI. Diferente do EU AI Act, não é lei, mas é uma espinha dorsal comum para a governança operacional da IA.",
|
|
117
|
+
"definition": "O Framework de Gestão de Riscos de IA do NIST é um framework voluntário que ajuda as organizações a governar, mapear, medir e gerir os riscos dos sistemas de IA enquanto perseguem as características da IA confiável.",
|
|
118
|
+
"scope": "Qualquer organização que projete, desenvolva, implante ou use IA, em qualquer setor. É voluntário e orientado a resultados, pensado para se adaptar ao contexto e ser usado junto a normas e regulação.",
|
|
119
|
+
"keyPoints": [
|
|
120
|
+
"Quatro funções centrais: Governar (cultura e prestação de contas), Mapear (contexto e riscos), Medir (avaliar e acompanhar), Gerir (priorizar e responder).",
|
|
121
|
+
"Governar é transversal: sustenta as outras três.",
|
|
122
|
+
"Define características de IA confiável a perseguir, não só riscos a evitar.",
|
|
123
|
+
"Um Perfil de IA Generativa (NIST AI 600-1) aborda os riscos específicos da GenAI.",
|
|
124
|
+
"Voluntário e flexível: pensado para se adaptar, não para se certificar.",
|
|
125
|
+
"Combina bem com a ISO/IEC 42001 (sistema de gestão) e o EU AI Act (lei)."
|
|
126
|
+
],
|
|
127
|
+
"controls": [
|
|
128
|
+
{ "control": "Governar", "note": "Estabeleça as políticas, a prestação de contas, a cultura e os papéis que tornam a gestão de riscos real: a base sobre a qual as demais funções se apoiam." },
|
|
129
|
+
{ "control": "Mapear", "note": "Estabeleça o contexto: uso pretendido, partes interessadas, e os riscos e impactos do sistema de IA antes de construir." },
|
|
130
|
+
{ "control": "Medir", "note": "Use métodos quantitativos e qualitativos para avaliar, comparar e monitorar o risco e a confiabilidade: você não gere o que não mede." },
|
|
131
|
+
{ "control": "Gerir", "note": "Priorize, responda e acompanhe os riscos ao longo do tempo, incluindo resposta a incidentes e descomissionamento." },
|
|
132
|
+
{ "control": "Características de confiabilidade", "note": "Direcione para resultados válidos, seguros, responsáveis, explicáveis, com privacidade reforçada e justos como metas de design explícitas." }
|
|
133
|
+
],
|
|
134
|
+
"checklist": [
|
|
135
|
+
"Coloque em marcha a função Governar: política, prestação de contas e papéis.",
|
|
136
|
+
"Mapeie o contexto, o uso pretendido, as partes interessadas e os riscos de cada sistema.",
|
|
137
|
+
"Defina métricas e Meça validade, segurança, viés e robustez.",
|
|
138
|
+
"Gerencie: priorize riscos, planeje respostas e acompanhe ao longo do tempo.",
|
|
139
|
+
"Aplique o Perfil de IA Generativa para os sistemas de GenAI.",
|
|
140
|
+
"Estabeleça resposta a incidentes e monitoramento para os sistemas implantados.",
|
|
141
|
+
"Mapeie o framework para suas obrigações sob a ISO 42001 e o EU AI Act."
|
|
142
|
+
],
|
|
143
|
+
"pitfalls": [
|
|
144
|
+
"Fazer Mapear e Medir mas negligenciar Governar, de modo que nada é responsável.",
|
|
145
|
+
"Medir o fácil em vez do que importa para a confiabilidade.",
|
|
146
|
+
"Tratá-lo como uma lista de verificação em vez de uma prática contínua de risco.",
|
|
147
|
+
"Ignorar o Perfil de IA Generativa para sistemas LLM e agênticos."
|
|
148
|
+
],
|
|
149
|
+
"examples": [
|
|
150
|
+
"Uma equipe que usa Mapear para documentar o uso pretendido e as partes interessadas de um agente antes de construir.",
|
|
151
|
+
"Um passo de Medir que compara um modelo em viés e robustez frente a um conjunto de avaliação.",
|
|
152
|
+
"Um processo de Gerir com resposta a incidentes para um assistente de GenAI implantado."
|
|
153
|
+
],
|
|
154
|
+
"faqs": [
|
|
155
|
+
{ "q": "O NIST AI RMF é obrigatório?", "a": "Não. É um framework voluntário. Mas é amplamente adotado como linguagem comum e espinha dorsal para a gestão operacional do risco de IA, e frequentemente referenciado em políticas e compras." },
|
|
156
|
+
{ "q": "Quais são as quatro funções?", "a": "Governar, Mapear, Medir e Gerir. Governar é transversal e sustenta as outras três, que percorrem o ciclo de vida da IA." },
|
|
157
|
+
{ "q": "Como aborda a IA generativa?", "a": "Por meio do Perfil de IA Generativa complementar (NIST AI 600-1), que identifica riscos específicos da GenAI e ações sugeridas mapeadas para as quatro funções." }
|
|
158
|
+
]
|
|
159
|
+
}
|
|
160
|
+
}
|
|
161
|
+
}
|