Báo cáo kinh nghiệm này đã được ẩn danh hóa (tổ chức ORG-1, doanh nhân E1). Nó không mô tả một giải pháp hoàn chỉnh, mà là một con đường: cách một hình mẫu trừu tượng — „tuân thủ được neo ngay trong chính .git“ — qua một loạt buổi làm việc đã trở thành một bản phác thảo nguyên mẫu có thể kiểm chứng. Bài học rút ra từ đó ít mang tính kỹ thuật hơn là phương pháp luận.

Bối cảnh ban đầu

ORG-1 liên kết nhiều pháp nhân: một tổ chức phi lợi nhuận, một công ty phát triển và chính doanh nhân E1 với tư cách là doanh nghiệp cá nhân. Từ sự kết hợp này nảy sinh ba câu hỏi tuân thủ khác nhau mà người ta dễ nhầm lẫn:

Trong thực tế, những câu hỏi này thường được trả lời „theo cảm tính“ — và chính ở đó nảy sinh những rủi ro mà một cuộc kiểm tra sau này sẽ làm lộ ra.

Cuộc trò chuyện như công cụ thiết kế

Điểm đặc biệt của dự án này: E1 làm việc với một tác nhân AI mã nguồn mở, cục bộ như một đối tác đối thoại. Không phải trình tạo mã, mà là một đối tác đối thoại, đọc bối cảnh doanh nghiệp hiện có (tài liệu, quy ước, các quyết định đã đưa ra) và cùng mài giũa trong cuộc trò chuyện.

Hiệu quả quyết định không phải là tốc độ, mà là tính nhất quán: Mỗi quyết định được đưa ra đều ngay lập tức được kiểm tra đối chiếu với kiến trúc hiện có — „điều này có phù hợp với những gì đã được quy định mang tính chuẩn tắc, hay chúng ta đang vô tình định nghĩa trùng lặp điều gì đó?“

Bài học 1: Một tác nhân chỉ tạo ra mà không kiểm tra hiện trạng sẵn có sẽ tạo ra sự dư thừa. Một tác nhân trước tiên tìm rồi sau đó mới đề xuất sẽ tạo ra tính nhất quán.

Thành phần đầu tiên: kiểm tra lĩnh vực dưới dạng call-back

Điều hiển nhiên lẽ ra là đưa logic lĩnh vực vào nơi cần đến nó — vào từng công cụ ghi nhận chứng từ. Cách đó không mở rộng được và phân tán cùng một quy tắc ra nhiều nơi.

Thay vào đó, người ta tìm thấy một mẫu đã có sẵn: một registry với các action-/call-identifier trong thư mục TOP/.gitcover riêng của từng tenant. Mỗi bước có thể thực thi mang một khóa ghép từ hai định danh — „nó là gì“ và „nó được thực thi như thế nào“. Khi đó, một công cụ không cần biết tổ chức chủ quản cụ thể: nó gọi một identifier, và một cơ chế phân giải xuyên các tầng (từ tenant cụ thể đến quy phạm chung) sẽ tìm ra handler chịu trách nhiệm.

Anfrage: "das ist ein gemeinnütziger Eintrag"
        │
        ▼
  Registry-Auflösung  (mandanten-spezifisch → normativ)
        │
        ├── gefunden  → Handler des Trägers (Sphärenprüfung § 60a)
        └── keiner    → bewusster No-Op (keine Prüfung nötig)

Nguyên tắc này gợi nhớ đến phân giải interface trong lập trình hướng đối tượng: người ta hỏi về một năng lực, không phải về một kiểu cụ thể. Tác dụng phụ: các tổ chức không vì mục đích công ích tự động nhận được một „không áp dụng“ gọn gàng — hoàn toàn không cần trường hợp đặc biệt trong mã.

Bài học 2: Một quy tắc áp dụng ở mọi nơi thuộc về một chỗ với một giao diện ổn định — không phải được sao chép vào từng công cụ.

Thành phần thứ hai: các hiện vật tuân thủ có thể tái tạo

Nhận thức thứ hai liên quan đến cách thức phân phối. Kiến thức quy định — các nguyên tắc GoBD, các nguyên tắc DSGVO, thời hạn lưu trữ — hiện nay nằm trong các sổ tay mà không ai đánh giá. Cách tiếp cận ở đây: kiến thức như vậy trở thành các hiện vật được phiên bản hóa, đọc được bằng máy trong kho Git.

Regulatorik  →  Katalog (maschinenlesbar)  →  Policies (ausführbar)
                                                     │
                                         Git-clone / Tool-Update
                                                     │
                                     prüfbares Ergebnis im Arbeitsverzeichnis

Hình mẫu không phải là CI/CD cho ứng dụng, mà là một „CI/CD cho dữ kiện doanh nghiệp“: Cùng một cơ chế cập nhật quen thuộc từ các công cụ phần mềm, ở đây mang kiến thức tuân thủ đi — được phiên bản hóa, có thể ký, có thể kiểm chứng.

Điều này có ý nghĩa gì cho thực tiễn

Bài học 3: „Từ khái niệm đến nguyên mẫu“ không có nghĩa là xây nhiều thứ mới. Nó có nghĩa là coi trọng bản thiết kế hiện có và đặt viên đá tiếp theo đúng chỗ.

Những gì được ký được phân định trong index

Một mẫu khác liên quan đến chính việc ký. Khi một tài liệu được đưa ra để ký (presented), chỉ các tài liệu gốc cần ký được đưa vào staging (git add) — nhờ đó Git-Index chỉ rõ ràng cái gì cần được ký, tách biệt khỏi phần còn lại của trạng thái làm việc. Một văn bản commit phù hợp được chuẩn bị; công cụ cố ý không commit (gc-docsign present …). Chỉ người ký mới ký commit đã được phân định (GPG). Như vậy, „bản trình“ và „chữ ký“ vẫn được tách bạch rõ ràng — và chứng từ không bị làm sai lệch.

Triển vọng

Bản phác thảo đã thành hình: một phép kiểm tra lĩnh vực tự phân giải ở nơi nó không cần thiết; một hệ thống quy tắc du hành như một hiện vật qua chính những kênh như mã. Việc từ đó có thành một công cụ hữu ích cho các tổ chức nhỏ khác hay không không do kỹ thuật quyết định — mà do sự sẵn sàng đặt mọi giả định trước một cuộc kiểm tra trước khi nó trở thành thói quen.

Báo cáo này đã được ẩn danh hóa (tổ chức ORG-1, doanh nhân E1). Đây là một phần của loạt bài Kinh nghiệm & Bài học kinh nghiệm.