Giới thiệu

Một tác nhân AI trở nên hữu ích trong tài chính và kế toán khi nó có thể làm việc với dữ liệu và công cụ kinh doanh mà nhân viên đã sử dụng. Những công cụ này có thể bao gồm bảng tính, hệ thống kế toán, cơ sở dữ liệu, kho tài liệu, dịch vụ dữ liệu thị trường và nền tảng phê duyệt nội bộ. Tác nhân không trở nên đáng tin cậy chỉ vì nó có thể gọi một công cụ. Độ tin cậy phụ thuộc vào việc chọn nguồn chính xác, xác thực dữ liệu trả về, bảo tồn khả năng truy nguyên và tôn trọng quyền truy cập của người dùng.

Một thiết kế thực tiễn coi mỗi hệ thống bên ngoài là một công cụ được kiểm soát với một hợp đồng rõ ràng. Hợp đồng nên nêu rõ công cụ làm gì, những đầu vào nào nó chấp nhận, đầu ra nào nó trả về, liệu hoạt động chỉ đọc dữ liệu hay thay đổi dữ liệu, và những vai trò nào có thể sử dụng nó. Ví dụ, một công cụ đọc bảng tính có thể trả về các hàng hóa đơn, trong khi một công cụ hệ thống kế toán có thể truy xuất các mục nhật ký đã đăng. Một hoạt động ghi như đăng một điều chỉnh nên yêu cầu kiểm soát mạnh mẽ hơn so với một hoạt động đọc như kiểm tra số dư tài khoản.

Bài học này tập trung vào lớp kết nối giữa tác nhân và dữ liệu kinh doanh. Nó đề cập đến các cuộc gọi công cụ có cấu trúc, xác thực, đối chiếu, hồ sơ kiểm toán và kiểm soát quyền truy cập. Nó không đề cập đến việc đào tạo một mô hình ngôn ngữ, thiết kế một nền tảng danh tính doanh nghiệp hoàn chỉnh, hoặc thay thế chính sách kế toán của tổ chức bằng các quyết định tự động.

Hợp đồng công cụ và ranh giới dữ liệu

Một hợp đồng công cụ cung cấp cho tác nhân một giao diện hẹp và có thể dự đoán. Xem xét một công cụ đọc bảng tính nhận một định danh workbook, một tên worksheet và một phạm vi. Kết quả của nó nên xác định nguồn, trả về các hàng yêu cầu ở định dạng có cấu trúc và báo cáo lỗi riêng biệt với dữ liệu kinh doanh. Tác nhân không nên được phép suy luận rằng một giá trị thiếu có nghĩa là không có gì, hoặc rằng một worksheet có tên tương tự tự động là nguồn chính xác.

Ví dụ sau đây cho thấy một mô phỏng công cụ cục bộ có thể chạy. Nó sử dụng dữ liệu trong bộ nhớ để minh họa mẫu kiểm soát mà không giả vờ kết nối với một API của nhà cung cấp cụ thể. Đầu vào là một yêu cầu chứa một workbook, worksheet và phạm vi được phép. Đầu ra là các hàng đã được xác thực hoặc một đối tượng lỗi rõ ràng.

from typing import Any

SPREADSHEETS = {
    "close-pack-2025-03": {
        "Invoices": [
            {"invoice_id": "INV-1001", "vendor_id": "V-10", "amount": 1250.00, "currency": "USD"},
            {"invoice_id": "INV-1002", "vendor_id": "V-11", "amount": 900.00, "currency": "USD"},
        ]
    }
}


def read_spreadsheet(workbook_id: str, worksheet: str, start_row: int, end_row: int) -> dict[str, Any]:
    if workbook_id not in SPREADSHEETS:
        return {"ok": False, "error": "WORKBOOK_NOT_FOUND"}
    if worksheet not in SPREADSHEETS[workbook_id]:
        return {"ok": False, "error": "WORKSHEET_NOT_FOUND"}
    if start_row < 0 or end_row < start_row:
        return {"ok": False, "error": "INVALID_RANGE"}

    rows = SPREADSHEETS[workbook_id][worksheet]
    selected = rows[start_row:end_row]
    return {
        "ok": True,
        "source": f"spreadsheet:{workbook_id}/{worksheet}",
        "rows": selected,
    }


result = read_spreadsheet("close-pack-2025-03", "Invoices", 0, 2)
print(result)

Trong ví dụ này, một kết quả thành công chứa định danh nguồn và hai bản ghi hóa đơn. Tên workbook, tên worksheet hoặc phạm vi không hợp lệ sẽ trả về các lỗi rõ ràng. Trong một tích hợp sản xuất, hợp đồng tương tự cũng cần xác thực, thời gian yêu cầu, xử lý giới hạn tỷ lệ, phiên bản lược đồ và bảo vệ chống lại việc truy xuất nhiều dữ liệu hơn mức cần thiết cho người dùng. Tác nhân chỉ nên nhận các trường cần thiết cho nhiệm vụ, đặc biệt khi các tệp bảng tính chứa thông tin về bảng lương, ngân hàng hoặc thông tin cá nhân có thể nhận diện.

Xác thực và Đối chiếu

Đầu ra của công cụ không tự động đáng tin cậy chỉ vì nó đến từ một hệ thống nội bộ. Một bảng tính có thể chứa các mã hóa đơn bị trùng lặp, văn bản nơi mà một số được mong đợi, thiếu đơn vị tiền tệ, hoặc một số tiền với dấu không mong đợi. Một cơ sở dữ liệu có thể chứa một bản ghi hợp lệ từ kỳ kế toán sai. Việc xác thực nên diễn ra trước khi tác nhân tóm tắt dữ liệu hoặc đề xuất một hành động.

Một quy trình xác thực hữu ích kiểm tra cấu trúc trước và ý nghĩa kinh doanh sau. Các kiểm tra cấu trúc xác nhận rằng các trường bắt buộc tồn tại và có các loại chấp nhận được. Các kiểm tra kinh doanh xác nhận các quy tắc như số tiền hóa đơn dương, đơn vị tiền tệ được phê duyệt, một thực thể khớp, hoặc một ngày kế toán nằm trong khoảng thời gian yêu cầu. Tác nhân nên báo cáo các ngoại lệ một cách rõ ràng thay vì im lặng sửa chữa chúng.

from decimal import Decimal, InvalidOperation


def validate_invoice_rows(rows: list[dict[str, object]]) -> list[dict[str, object]]:
    errors = []
    seen_ids = set()
    allowed_currencies = {"USD", "EUR", "GBP"}

    for index, row in enumerate(rows):
        invoice_id = row.get("invoice_id")
        amount = row.get("amount")
        currency = row.get("currency")

        if not invoice_id:
            errors.append({"row": index, "field": "invoice_id", "error": "REQUIRED"})
        elif invoice_id in seen_ids:
            errors.append({"row": index, "field": "invoice_id", "error": "DUPLICATE"})
        else:
            seen_ids.add(invoice_id)

        try:
            if Decimal(str(amount)) <= 0:
                errors.append({"row": index, "field": "amount", "error": "MUST_BE_POSITIVE"})
        except (InvalidOperation, TypeError):
            errors.append({"row": index, "field": "amount", "error": "NOT_NUMERIC"})

        if currency not in allowed_currencies:
            errors.append({"row": index, "field": "currency", "error": "UNSUPPORTED"})

    return errors


validation_errors = validate_invoice_rows(result["rows"] if result["ok"] else [])
print({"valid": not validation_errors, "errors": validation_errors})

Đầu vào là một danh sách các từ điển hóa đơn, và đầu ra chứa một kết quả hợp lệ Boolean và bất kỳ lỗi nào được phát hiện. Lưu ý rằng hàm không quyết định phải làm gì với một hóa đơn không hợp lệ. Nó báo cáo vấn đề để một quy trình làm việc có nhận thức về chính sách có thể chuyển nó đến một kế toán viên, yêu cầu làm rõ, hoặc dừng lại trước khi đăng. Sự tách biệt này giữ cho các quy tắc xác thực có thể kiểm tra và ngăn chặn một mô hình ngôn ngữ tự phát minh ra một sự sửa chữa.

Đối chiếu thêm một nguồn thứ hai. Ví dụ, tác nhân có thể so sánh các hóa đơn trong bảng tính với các bản ghi tài khoản phải trả đã được phê duyệt. Nó nên khớp trên các mã định danh ổn định khi có thể, so sánh các số tiền bằng cách sử dụng số học thập phân, và làm cho đơn vị tiền tệ và khoảng thời gian trở nên rõ ràng. Một kết quả nên phân biệt các bản ghi đã khớp, sự không khớp về số tiền, các bản ghi thiếu từ một nguồn, và các bản ghi không thể khớp một cách tự tin.

Kiểm soát Truy cập và Khả năng Theo dõi

Kiểm soát truy cập phải được thực thi bởi lớp công cụ và các hệ thống kết nối, không chỉ bằng các hướng dẫn trong prompt của tác nhân. Công cụ nên nhận diện danh tính người dùng, vai trò, người thuê hoặc thực thể pháp lý, và hoạt động yêu cầu. Nó nên xác minh xem danh tính đó có thể đọc dữ liệu đã chọn hoặc thực hiện ghi yêu cầu hay không. Một người dùng có thể yêu cầu một báo cáo không tự động được ủy quyền để phê duyệt một mục nhật ký.

Các giai đoạn đọc, chuẩn bị và cam kết riêng biệt giúp các quy trình tài chính dễ kiểm soát hơn. Tác nhân có thể đọc các bản ghi và chuẩn bị một đối chiếu đề xuất. Một người hoặc một dịch vụ phê duyệt chuyên dụng có thể xem xét đề xuất. Chỉ một hoạt động cam kết được ủy quyền mới nên tạo một mục đăng, cập nhật bản ghi nhà cung cấp, hoặc thay đổi trạng thái thanh toán. Đối với các hành động có rủi ro cao, sử dụng phê duyệt kép, giới hạn giao dịch, và một xác nhận rõ ràng bao gồm mục tiêu chính xác, số tiền, đơn vị tiền tệ, và khoảng thời gian kế toán.

Khả năng theo dõi có nghĩa là một người xem xét khác có thể tái tạo những gì đã xảy ra. Một sự kiện kiểm toán nên ghi lại danh tính yêu cầu, thời gian, tên công cụ, hoạt động, tham chiếu đầu vào, trạng thái kết quả, phát hiện xác thực, và mã định danh tương quan. Không đặt các hàng bí mật đầy đủ vào nhật ký khi một tham chiếu nguồn, băm, hoặc tóm tắt đã được biên soạn là đủ. Nhật ký cũng phải được bảo vệ chống lại sự sửa đổi trái phép và được giữ lại theo chính sách của tổ chức.

Giải thích bằng ngôn ngữ tự nhiên của tác nhân nên chỉ ra bằng chứng. Thay vì nói rằng một hóa đơn có vẻ đúng, nó nên nêu rõ các bản ghi nguồn nào đã được so sánh, các trường nào đã khớp, và liệu có bất kỳ ngoại lệ nào còn lại hay không. Một trích dẫn đến một phạm vi bảng tính, mã định danh kết quả truy vấn cơ sở dữ liệu, hoặc số tài liệu kế toán làm cho kết luận có thể xem xét mà không tiết lộ nhiều dữ liệu hơn mức cần thiết.

Các Chế độ Thất bại Thường gặp

Một sai lầm phổ biến là kết nối trực tiếp tác nhân với một cơ sở dữ liệu rộng và cho phép nó tạo ra các truy vấn không bị hạn chế. Điều này tạo ra sự phơi bày dữ liệu quá mức và khiến việc chứng minh lý do tại sao một kết quả được sản xuất trở nên khó khăn. Sử dụng các thao tác đã định nghĩa trước hoặc các công cụ truy vấn có phạm vi hẹp, xác thực tham số, giới hạn hàng và bộ lọc theo thực thể. Từ chối các yêu cầu cố gắng vượt qua những ranh giới đó.

Một sai lầm khác là coi bảng tính như một hồ sơ kế toán chính thức trong mọi tình huống. Bảng tính thường là tài liệu làm việc hữu ích, nhưng chúng có thể đã lỗi thời, được chỉnh sửa thủ công hoặc không liên kết với trạng thái đăng. Quy trình làm việc nên gán nhãn mỗi nguồn theo thẩm quyền và dấu thời gian của nó. Khi các nguồn không đồng ý, tác nhân nên làm nổi bật xung đột và xác định bước xem xét tiếp theo thay vì chọn im lặng.

Một sai lầm thứ ba là cho phép một cuộc gọi công cụ thành công ngụ ý một kết quả kinh doanh thành công. Một hệ thống có thể trả về phản hồi kỹ thuật hợp lệ trong khi hồ sơ nằm ngoài thời gian báo cáo, đã được đăng, hoặc chịu sự hạn chế phân tách nhiệm vụ. Do đó, xác thực và ủy quyền kinh doanh phải diễn ra sau khi truy xuất dữ liệu và trước bất kỳ thao tác ghi nào.

Các lỗi cũng cần được xử lý nhất quán. Các lỗi xác thực nên dừng quy trình làm việc và yêu cầu xác thực lại. Các hồ sơ bị thiếu nên được báo cáo là thiếu, không chuyển đổi thành giá trị bằng không. Thời gian chờ và giới hạn tần suất có thể được thử lại theo các quy tắc kiểm soát, nhưng một lỗi lặp lại nên tạo ra một kết quả không hoàn chỉnh với trạng thái rõ ràng. Các kết quả không rõ ràng nên được nâng cao, đặc biệt khi chúng có thể ảnh hưởng đến báo cáo tài chính hoặc thanh toán.

Quy trình làm việc thực tiễn và Tóm tắt

Một quy trình làm việc của tác nhân đáng tin cậy bắt đầu bằng việc làm rõ mục tiêu của người dùng, thực thể pháp lý, thời gian và thao tác yêu cầu. Sau đó, nó kiểm tra quyền truy cập của người dùng, chọn tập hợp công cụ được phê duyệt nhỏ nhất, truy xuất dữ liệu với các tham chiếu nguồn, xác thực sơ đồ và quy tắc kinh doanh, và so sánh các nguồn khi cần hòa giải. Tác nhân sản xuất một kết quả với các ngoại lệ và bằng chứng, sau đó tạm dừng trước bất kỳ thao tác ghi hoặc phê duyệt nào được kiểm soát.

Để thực hành, hãy tưởng tượng một người dùng yêu cầu tác nhân hòa giải các hóa đơn tháng Ba. Tác nhân nên xác định bảng tính và nguồn kế toán đã được phê duyệt, xác minh rằng người dùng có thể truy cập cả hai, chỉ truy xuất các hồ sơ tháng Ba, xác thực các định danh, số tiền, loại tiền tệ và trạng thái, và phân loại từng kết quả. Nó có thể chuẩn bị một báo cáo hòa giải, nhưng không nên đăng các điều chỉnh chỉ vì có sự không khớp. Một người xem xét hoặc quy trình làm việc đã được phê duyệt phải quyết định cách giải quyết sự không khớp.

Nguyên tắc trung tâm là quyền truy cập công cụ mở rộng khả năng của một tác nhân và cũng mở rộng rủi ro của nó. Các hợp đồng có cấu trúc, quyền hạn tối thiểu, xác thực rõ ràng, tham chiếu nguồn và sự kiện kiểm toán giữ cho khả năng đó được giới hạn. Khi một tác nhân không thể xác minh nguồn, quyền hạn hoặc quy tắc kinh doanh, hành vi đúng là dừng lại, giải thích sự không chắc chắn và yêu cầu một cuộc xem xét thích hợp thay vì tạo ra sự tự tin.