Trục 1: Nền tảng

Git-native Compliance

Luận điểm cốt lõi của GCBoK:

Git-native Compliance có nghĩa là tất cả các hiện vật tuân thủ, quyết định, danh tính và bằng chứng đều nằm chủ yếu trong các Git-Repository - được phiên bản hóa, ký bằng GPG, đọc được bằng máy theo OSCAL, kiểm chứng được bằng OPA - mà không cần đến một Compliance-Store thứ cấp.

Vị trí trong phổ paradigm

Paradigm	Lĩnh vực	Nguồn chân lý
Cloud-native	Hạ tầng	CNCF
GitOps	Triển khai	OpenGitOps Working Group
Git-native Compliance	Tuân thủ	GCBoK

Ba trụ cột của Git-native Compliance

1. Neo giữ bằng mật mã - Mỗi mục nhập trong một Git-Repository đều được bảo đảm bằng một hash, tùy chọn kèm chữ ký GPG. Nhờ đó có thể chứng minh được: Ai, Cái gì, Khi nào. Điều này đáp ứng các yêu cầu của GoBD về tính không thể thay đổi - nhưng một cách native nhờ chính kiến trúc Git.

2. Khả năng đọc bằng máy - OSCAL (Open Security Controls Assessment Language) cho các kiểm soát an ninh và kết quả đánh giá. OPA/Rego (Open Policy Agent) cho các quy tắc tuân thủ dưới dạng mã, được kiểm tra tự động đối chiếu với Git-State.

3. Tính tất định nhờ V7GUID - Mỗi đối tượng tuân thủ đều có thể được định địa chỉ toàn cầu một cách duy nhất (UUIDv7), sắp xếp được theo thời gian (dấu thời gian 48-bit), phân loại được (mã định danh lớp 14-bit) và có thể liên kết với nhau thành chuỗi chứng từ.

Tự tham chiếu không rơi vào Vendor Lock-In

Git-native Compliance có tính tự tham chiếu: Tất cả các thành phần GitCover - nguồn, tham chiếu, biện pháp, tài liệu - đều được định địa chỉ và quản lý chỉ thông qua các Git-Repository. Sự thật nằm ngay trong chính .git (các commit, tree, hash), không nằm trong các dịch vụ bên ngoài, wiki hay ticket. Điều này tránh được Vendor Lock-In: Từng repository tự bản thân nó đã an toàn chống sửa đổi, có tính di động và không có bất kỳ phụ thuộc độc quyền nào.

Chuẩn hash: luôn SHA-256, không bao giờ SHA-1

Mỗi GitCover-Repository được tạo với SHA-256 làm hàm hash đối tượng (git init --object-format=sha256 hoặc extensions.objectformat = sha256). SHA-1 bị nghiêm cấm rõ ràng (tấn công va chạm). Nhờ vậy, việc neo giữ bằng mật mã (trụ cột 1) được xây dựng trên một chuẩn hash được chứng minh là an toàn.

Vị trí lưu trữ các công cụ GitCover

Tất cả công cụ, dịch vụ của GitCover và (trong tương lai) MCP-Server được đặt phù hợp với kế hoạch tại /opt/GitCover/ (ví dụ: WebStaticBuilder-CLI tại /opt/GitCover/webstatic). Điều này tránh được các nơi lưu trữ toàn hệ thống, không được phiên bản hóa. Sau khi hoàn tất onboarding, /opt/GitCover bản thân nó sẽ trở thành một Git-Repository, nơi các tham số môi trường tuân thủ GoBD (BASE_URL, CDN, đường dẫn, phiên bản công cụ) được tài liệu hóa kèm phiên bản.

Tuân thủ như một hạ tầng

GitCover không phải là công cụ dành cho những người đam mê tuân thủ. Nó là hạ tầng dành cho tất cả những ai muốn hoàn thành công việc tuân thủ. Điều đó có nghĩa là:

Chi phí thấp nhất có thể - Open Source, không có giấy phép độc quyền
An toàn tối đa - Neo giữ bằng mật mã, không thông qua các lớp phần mềm
Khả năng chứng minh đầy đủ - Lịch sử Git như một Audit-Trail tích hợp sẵn

Mô hình kiến trúc: Các ứng dụng nghiệp vụ dọc và Compliance-Backbone ngang

flowchart TB subgraph HorizotalBackbone["Horizontaler GitCover® Compliance-Backbone"] GitCover["Git Repos/Features · TOP · PII · OSCAL · OPA · GPG · V7GUID · etc."]:::coverBar end subgraph VertikaleAnwendungen["Vertikale Fachanwendungen (Beispiele)"] direction TB FiBu["Finanzbuchhaltung"] Zeit["Zeiterfassung"] Lohn["Lohnabrechnung"] Mails["Geschäftskorrespondenz"] OPos["E-Rechnung Eingang/Ausgang"] end FiBu <-->|"Revisionssichere Ablage
Beleg-Ketten"| GitCover Zeit <-->|"Policy-Validierung"| GitCover Lohn <-->|"SV/AO/GoBD-Nachweise"| GitCover Mails <-->|"E-Mail-Archivierung"| GitCover OPos <-->|"XML-Daten, Audit-Trails"| GitCover subgraph KISchicht["KI-Agenten-Ebene"] Agent["KI-Compliance-Agent
(eingesperrt im Worktree)"]:::agentBar end Agent -->|"liest/schreibt
nur im zugewiesenen Repo"| GitCover Agent -.->|"OPA-Guardrails
als Pre-Receive-Hooks"| GitCover classDef coverBar fill:#6B7280,color:#FFFFFF,stroke:#4B5563,stroke-width:2px,rx:6,ry:6,min-width:100%,font-size:1.1em,padding:6px,margin:6px; classDef agentBar fill:#0A7F5C,color:#FFFFFF,stroke:#0A7F5C,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px,margin:4px;

Cách đọc: Các ứng dụng nghiệp vụ dọc (kế toán tài chính, chấm công, tính lương, ERP, kho) vẫn độc lập về nội dung và tự chủ về nghiệp vụ. GitCover tạo thành lớp ngang: các Git-Repository như một Compliance-Backbone xuyên suốt, kết nối từng ứng dụng dọc với các danh mục OSCAL, OPA-Policies, chữ ký GPG và chuỗi chứng từ V7GUID - không cần middleware độc quyền và không cần Compliance-Store thứ cấp.

Khung pháp lý

GCBoK đề cập đến các khung quy định sau đây:

GoBD - Các nguyên tắc về hệ thống kế toán hỗ trợ bằng xử lý dữ liệu đúng chuẩn mực

GoBD (Rz. 151-157) yêu cầu một hệ thống kiểm soát nội bộ, khả năng truy vết, tính không thể thay đổi và tính đúng thời điểm. Git-native Compliance đáp ứng các yêu cầu này một cách native:

Yêu cầu của GoBD	Cách đáp ứng Git-native
Khả năng truy vết	Lịch sử Git (commit-log)
Tính không thể thay đổi	Git-Hash + chữ ký SSH-/GPG
Tính đúng thời điểm	Dấu thời gian V7GUID (UUIDv7)
Hệ thống kiểm soát nội bộ	OPA-Policies dưới dạng Pre-Receive-Hooks

NIS2 - Network and Information Security Directive

Chỉ thị EU-NIS2 yêu cầu quản trị rủi ro và nghĩa vụ báo cáo đối với các hạ tầng trọng yếu. GCBoK định nghĩa các phương pháp phân tích rủi ro NIS2 dựa trên các Git-Repository.

BSI GS++ & GCBoK Compliance-as-Code

Bộ BSI IT-Grundschutz-Kompendium định nghĩa các tiêu chuẩn về an toàn thông tin và ngày càng cung cấp chúng dưới các định dạng đọc được bằng máy (như OSCAL). GCBoK sử dụng các danh mục OSCAL được chuẩn hóa này và ánh xạ các kiểm soát BSI trực tiếp vào các quy trình tuân thủ Git-native, tự động hóa (Compliance-as-Code). Nó chuyển đổi các quy định pháp lý của BSI thành các quy trình kiểm tra có thể vận hành bên trong hệ sinh thái GitCover.

DSGVO - Quy định chung về bảo vệ dữ liệu

DSGVO yêu cầu Privacy by Design. GCBoK định nghĩa các bằng chứng danh tính phi tập trung (bao gồm cả danh tính PGP), vốn neo giữ dữ liệu cá nhân không trong các cơ sở dữ liệu tập trung mà trong các cấu trúc Git.

Hiểu biết về việc sử dụng

Các nguyên tắc kiến trúc của GCBoK cần phải dễ nắm bắt đối với người dùng có ít kiến thức IT. Phần này truyền đạt những mô hình tư duy giúp người không chuyên hiểu được cách làm việc với Git-native Compliance.

Files over Apps - Nguyên tắc chỉ đạo

GCBoK tuân theo nguyên tắc chỉ đạo Files over Apps: Các hiện vật tuân thủ tồn tại dưới dạng tệp trong các Git-Repository, chứ không nằm trong các cơ sở dữ liệu ứng dụng độc quyền. Các cuộc hội thoại, tài liệu, chứng từ và policy là các tệp Markdown, YAML hoặc JSON trong Git-Tree - được phiên bản hóa, có thể ký, có thể kiểm toán. Ứng dụng có thể thay thế; tệp thì tồn tại bền vững.

Điều này khác biệt căn bản so với paradigm ứng dụng cổ điển, trong đó phần mềm giữ dữ liệu trong cơ sở dữ liệu riêng của nó và việc xuất dữ liệu là một nhu cầu phát sinh về sau. Với Git-native Compliance, việc xuất dữ liệu chính là trạng thái bình thường.

Cặp hồ sơ số - Mô hình tư duy

Đối với người dùng ít hiểu biết về máy tính, khái niệm về một hệ thống tệp hoàn chỉnh là trừu tượng và dễ gây lỗi. Phép ẩn dụ về cặp hồ sơ số giải quyết vấn đề này:

Git-Working-Directory không phải là một thư mục PC rối ren, mà là một cặp hồ sơ số với máy photocopy và sổ nhật ký (Git) tích hợp sẵn.
Quy tắc: Một AI Agent chỉ được phép đọc và ghi trong thư mục cụ thể này. Mọi thứ bên ngoài đều không tồn tại đối với nó.
Khả năng hiển thị: Mọi thay đổi mà AI thực hiện đều được đánh dấu ngay lập tức là thay đổi (Git-Status). Người không chuyên sẽ thấy: „AI đã thay đổi dòng 4 trong tài liệu quy trình."
Sự an toàn: Git-Staging-Area trở thành cửa sổ xem trước và phê duyệt. Người dùng không cần hiểu Git - họ hiểu nguyên lý: „AI đề xuất một thay đổi, tôi nhấp vào Chấp nhận (Commit)."

Nguyên tắc hộp cát

Đối với việc tuân thủ GoBD và NIS2, việc giới hạn phạm vi truy cập là điều nền tảng. Một AI Agent chỉ có thể truy cập Git-Working-Directory được chỉ định thì bị nhốt hoàn toàn về mặt vật lý:

Ngay cả khi agent bị ảo giác hoặc bị thao túng qua Prompt-Injection, nó cũng không thể thoát ra khỏi Git-Repository.
Giải thích cho người dùng: „AI bị nhốt trong thư mục dự án này. Nó không thể gây hại cho phần còn lại của hệ thống."
Mọi hoạt động tuân thủ đều được ghi lại trong lịch sử Git như một mạng an toàn - người dùng giữ trọn quyền chủ động.

So sánh các môi trường làm việc AI

GCBoK trung lập về công nghệ đối với môi trường làm việc AI. Có ba paradigm để lựa chọn:

Tiêu chí	WebUI-first (Trình duyệt)	Desktop-Client (Ứng dụng native)	Nền tảng All-in-One
Paradigm	Proxy cấp OS, truy cập hệ thống tệp qua trình duyệt	Client-first, điều phối agent cục bộ/SSH	Workspace hoàn chỉnh (Chat, Mail, Tài liệu, Lịch)
Trọng tâm	Quản lý tệp, Git-Staging, Terminal qua trình duyệt	Hệ sinh thái agent, Skill-Store, đa agent	Hub năng suất, thay thế SaaS cục bộ/riêng tư
Sandbox	Docker-Bind-Mounts, cô lập Git-Worktree	API-Gating, giới hạn token, quyền hạn cục bộ	Docker-Container, đóng gói kín
Ưu điểm	Tích hợp Git liền mạch, Files over Apps	Hiệu năng cao, tích hợp công cụ chặt chẽ	Mạnh mẽ, mọi công việc văn phòng trong một giao diện
Nhược điểm	Mô hình an toàn đòi hỏi cấu hình mount cẩn thận	Cấu hình đòi hỏi hiểu biết kỹ thuật	Hạ tầng Docker, dữ liệu bị ràng buộc trong DB riêng
Độ phù hợp GCBoK	Rất cao - về triết lý đúng chính xác „Files over Apps"	Trung bình - rào cản cấu hình cho người không chuyên	Thấp - dữ liệu không được lưu trữ theo kiểu Git-native

Khuyến nghị: Mô hình appliance kết hợp

Dành cho người dùng doanh nghiệp vừa và nhỏ không có kiến thức IT sâu, GCBoK khuyến nghị một mô hình appliance kết hợp:

Đóng gói hạ tầng (tập trung): Một máy chủ AI headless trong LAN đảm nhiệm suy luận LLM và quản lý Git. Sự phức tạp được chuyển dời hoàn toàn đến đó.
Nơi làm việc client tối giản: Người dùng cuối không bị ép phải có Docker cục bộ, Python hay Git nào trên desktop của mình. Họ chỉ truy cập giao diện web thông qua trình duyệt (dưới dạng PWA).
Luồng tương tác: Người dùng sử dụng các chức năng chat và ghi chú. Khi muốn kiểm tra hoặc tạo tài liệu tuân thủ, AI Agent làm việc ngầm trực tiếp trên các thư mục của máy chủ tệp tập trung. Agent đảm nhận Staging, Commit và Push vào Gitea-Repository - người dùng thấy một danh sách kiểm tra trực quan trong UI.

Mục tiêu: Người dùng không trải nghiệm một „AI điều khiển máy tính", mà là một nhân viên nghiệp vụ thông minh cho thư mục tuân thủ cụ thể. Họ biết AI đang làm việc ở đâu, thấy từng bước trong lịch sử Git và giữ trọn quyền chủ động mà GCBoK yêu cầu.

Kiến trúc tham chiếu: Mô hình appliance kết hợp

flowchart TB subgraph Client["Client-Ebene (minimal)"] Browser["Browser / PWA
kein Docker, kein Git lokal"]:::clientBar end subgraph KIServer["KI-Server im LAN (headless)"] OWUI["Web-Oberfläche
(Chat + Notizen)"]:::serverBar Agent["KI-Agent
(im Git-Worktree eingesperrt)"]:::agentBar Ollama["LLM-Inferenz
(Ollama, lokal)"]:::serverBar end subgraph FileServer["File-Server / Git-Host"] Gitea["Gitea
(Git-Repositories + IdP)"]:::storageBar Repos["Git-Working-Directories
pro Mandant isoliert"]:::storageBar end Browser -->|"HTTPS"| OWUI OWUI --> Agent Agent -->|"liest/schreibt
nur im zugewiesenen Worktree"| Repos Agent -->|"LLM-Anfrage"| Ollama Agent -->|"Commit + Push"| Gitea Gitea --- Repos classDef clientBar fill:#2563EB,color:#FFFFFF,stroke:#1D4ED8,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef serverBar fill:#6B7280,color:#FFFFFF,stroke:#4B5563,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef agentBar fill:#0A7F5C,color:#FFFFFF,stroke:#0A7F5C,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px; classDef storageBar fill:#92400E,color:#FFFFFF,stroke:#78350F,stroke-width:2px,rx:6,ry:6,font-size:1em,padding:4px;

Xem thêm: Việc triển khai thực tế các khung này được mô tả trong Trục 5: Cách tiếp cận.