Cách chọn API phát hiện AI: mười điểm cần kiểm tra trước khi tích hợp

Để chọn một API phát hiện AI đủ tin cậy cho môi trường sản xuất, hãy kiểm tra mười điều quyết định nó có chạy ổn định hay không: API kiểm tra và trả về những gì, giới hạn đầu vào, cách giao kết quả, webhook có được ký hay không, việc thử lại có an toàn không, lỗi và giới hạn tốc độ hoạt động ra sao, API lưu dữ liệu gì và trong bao lâu, kết quả có kiểm toán được và gắn với một phiên bản mô hình hay không, và một lượt kiểm tra thất bại hoặc một yêu cầu thử nghiệm tốn bao nhiêu. Phần lớn câu trả lời có sẵn trong tài liệu của nhà cung cấp trước khi bạn viết bất kỳ dòng mã nào. Phần còn lại cần một đợt thí điểm ngắn.

Hướng dẫn này dành cho kỹ sư và người mua công nghệ ở công ty bảo hiểm, ngân hàng, công ty tài chính, sàn thương mại điện tử và các đội vận hành khác đang tích hợp một dịch vụ phát hiện AI vào quy trình tiếp nhận hồ sơ, xử lý bồi thường, tiếp nhận khách hàng mới (onboarding) hoặc kiểm duyệt nội dung. Hướng dẫn đánh giá giao diện API, không đánh giá bộ phát hiện. Về độ chính xác, dương tính giả và khối lượng xét duyệt, hãy xem hướng dẫn chọn phần mềm phát hiện ảnh AI và hướng dẫn về độ chính xác. Một bộ phát hiện cho kết quả tốt trên tệp của bạn vẫn có thể thất bại khi vận hành nếu phần API đi kèm khó thử lại, khó kiểm toán hoặc khó kiểm soát chi phí.

Mỗi điểm kiểm tra dưới đây nêu lý do nó quan trọng, cách xác minh trong tài liệu của bất kỳ nhà cung cấp nào và những gì tài liệu của API Fileverity nêu về điểm đó, kèm liên kết tới tài liệu API. Mười câu hỏi này áp dụng được cho mọi phương án, và hướng dẫn không nêu tên hay xếp hạng nhà cung cấp nào.

Tổng quan mười điểm kiểm tra

Hình dưới đây cho biết mỗi điểm kiểm tra có thể được trả lời từ nguồn nào. Tài liệu cho bạn biết nhà cung cấp cam kết điều gì, khóa thử nghiệm cho thấy cấu trúc yêu cầu và phản hồi, và chỉ một đợt thí điểm trên tệp của bạn mới cho thấy thời gian xử lý, việc xóa dữ liệu và cách tính phí.

Phạm vi và đầu vào

Loại tác vụ và kết quả trả về

Vì sao quan trọng. “Phát hiện AI” gồm nhiều tác vụ khác nhau: một ảnh có được tạo ra hoặc chỉnh sửa bằng AI hay không, một tài liệu có bị sửa hoặc chứa đoạn do AI viết hay không, một đoạn văn bản thuần có do AI viết hay không. Nhà cung cấp làm được tác vụ này chưa chắc làm được tác vụ khác. Một phản hồi chỉ là một con số, không nêu phạm vi và bằng chứng, rất khó dùng làm căn cứ hành động và khó bảo vệ khi bị khiếu nại. Người xét duyệt cần biết một phát hiện nói về điều gì, còn logic định tuyến của bạn cần một trường ổn định, máy đọc được.

Cách xác minh. Liệt kê các tác vụ bạn cần và tìm từng tác vụ trong tài liệu theo đúng tên. Mở lược đồ phản hồi và tìm bốn yếu tố: một phần tóm tắt máy đọc được (kết luận, mức độ hoặc hành động khuyến nghị) tách khỏi các phát hiện chi tiết; bằng chứng để con người đọc; một trạng thái “không đánh giá được” khác với “âm tính”; và một phiên bản lược đồ. Hãy yêu cầu phản hồi mẫu cho trường hợp bị gắn cờ, trường hợp không có vấn đề, trường hợp chưa đủ cơ sở để kết luận và trường hợp lỗi. Nếu đội xét duyệt của bạn làm việc bằng tiếng Việt, hãy kiểm tra thêm hai điều: ngôn ngữ đầu vào được hỗ trợ cho từng tác vụ, và ngôn ngữ của phần giải thích kết quả. Ma trận đáp ứng trong hướng dẫn chọn phần mềm cho thấy cách ghi lại các câu trả lời.

Tài liệu của Fileverity nêu. Ba mô hình, mỗi mô hình được liệt kê cùng giới hạn và snapshot qua GET /models: fvimg-2 cho ảnh, fvdoc-3 cho tài liệu và fvdoc-3-text cho văn bản thuần. Kiểm tra ảnh và tài liệu trả về báo cáo đầy đủ gồm mức tóm tắt và hành động khuyến nghị, các phát hiện chi tiết, mã báo cáo và một PDF được niêm phong. Kiểm tra văn bản trả về kết quả gồm kết luận (do AI viết, hỗn hợp hoặc do con người viết), điểm số và các đoạn được đánh dấu. Tài liệu nêu rõ kết quả văn bản chỉ là ước tính thống kê, không phải bằng chứng về tác giả, và không nên là căn cứ duy nhất cho quyết định ảnh hưởng đến một người. Về ngôn ngữ, kiểm tra văn bản thuần chấp nhận tiếng Anh, tiếng Pháp, tiếng Đức, tiếng Tây Ban Nha và tiếng Trung, không áp dụng cho tiếng Việt. Phần giải thích các phát hiện về tài liệu (tùy chọn options.locale) cũng chỉ có năm ngôn ngữ đó, mặc định là en. Với tài liệu viết chủ yếu bằng tiếng Việt, hãy chạy mẫu thử và đọc kỹ báo cáo ghi gì về phần văn bản. Xem các trang tài liệu Tổng quan, Đối tượng báo cáo và Phát hiện văn bản, hoặc các trang API phát hiện ảnh AI và API phát hiện giả mạo tài liệu.

Giới hạn đầu vào

Vì sao quan trọng. Giới hạn quyết định đầu vào thực tế của bạn có nằm trong phạm vi xử lý hay không: ảnh chụp bằng điện thoại, ảnh chụp màn hình, bản quét, PDF nhiều trang, tệp có mật khẩu, văn bản dài. Một giới hạn mà bạn chỉ gặp lần đầu khi đã vận hành thật sẽ biểu hiện thành các yêu cầu thất bại và người dùng phàn nàn.

Cách xác minh. Tìm giới hạn của từng loại tác vụ: định dạng được chấp nhận, kích thước tối đa, số điểm ảnh hoặc số trang, độ dài văn bản và ngôn ngữ. Kiểm tra cách tải tệp lớn (một yêu cầu hay tải lên bằng URL đã ký sẵn), định dạng được nhận diện từ nội dung tệp hay chỉ dựa vào tên tệp, và mỗi trường hợp vượt giới hạn trả về gì. Một mã lỗi riêng là dấu hiệu tốt; cắt bớt âm thầm hay một lỗi 400 chung chung thì không. Sau đó hãy gửi những tệp lớn nhất, nhỏ nhất và khó xử lý nhất mà bạn thực sự nhận, chẳng hạn ảnh chụp màn hình chuyển khoản, bản quét hồ sơ bồi thường nhiều trang hoặc tệp PDF hóa đơn điện tử.

Tài liệu của Fileverity nêu. Trang Tệp nêu các định dạng và giới hạn được hỗ trợ cho từng mô hình, cách tải lên trực tiếp dạng multipart và tải lên bằng URL đã ký sẵn cho tệp lớn hơn, việc nhận diện định dạng từ nội dung tệp, và một mã lỗi riêng cho mỗi giới hạn. Với tài liệu được mã hóa, hãy dùng tùy chọn mật khẩu (xem Phân tích). Độ dài văn bản và ngôn ngữ nằm trong Phát hiện văn bản.

Kết quả và cách giao kết quả

Chờ kết quả

Vì sao quan trọng. Một lệnh gọi mất vài giây trong môi trường thử có thể lâu hơn khi tải cao, và nền tảng của bạn cũng có giới hạn thời gian chờ: hàm serverless, API gateway, yêu cầu của người dùng. Nhà cung cấp trả kết quả theo một trong hai cách. Lệnh gọi đồng bộ trả kết quả ngay trong phản hồi. Lệnh gọi bất đồng bộ trả về ngay với một trạng thái, và bạn lấy kết quả sau. Một tích hợp viết cho cách thứ nhất mà gặp cách thứ hai sẽ bỏ sót kết quả hoặc chặn người dùng. Hình dưới đây cho thấy ba cách một kết quả bất đồng bộ đến được hệ thống của bạn.

Cách xác minh. Tìm vòng đời trạng thái (processing, succeeded, failed, canceled) và, nếu nhà cung cấp có thể giữ yêu cầu mở, thời gian chờ tối đa được ghi trong tài liệu. Kiểm tra cách truy vấn định kỳ (polling) và tần suất cho phép, điều gì xảy ra khi hệ thống bận, hàng đợi có báo vị trí không và có hủy được công việc mà không bị tính phí không. Phản hồi 503 kèm header Retry-After, được định nghĩa trong RFC 9110 (tiếng Anh), cho chương trình của bạn biết cần làm gì. Trong đợt thí điểm, hãy đo thời gian từ đầu đến cuối ở khối lượng dự kiến cho loại tệp chậm nhất của bạn. Một chế độ thử nghiệm trả lời tức thì không cho bạn biết gì về điều này.

Tài liệu của Fileverity nêu. Kiểm tra văn bản là đồng bộ: kết quả nằm ngay trong phản hồi. Kiểm tra ảnh và tài liệu là bất đồng bộ: tạo một lượt kiểm tra trả về 202 với status: processing. Bạn có thể giữ yêu cầu mở bằng header Prefer: wait, truy vấn GET /analyses/{id} hoặc đăng ký webhook, và nên xử lý 202 ngay cả khi chờ, vì các tệp tài liệu có thể phải xếp hàng. Khi hệ thống bận, lệnh tạo trả về 503 service_unavailable kèm retry-after và không bị tính phí. Một lượt kiểm tra tài liệu còn đang xử lý có thể hủy mà không bị tính phí. Xem các trang tài liệu Chờ, truy vấn định kỳ hoặc dùng webhook và Khi dịch vụ đang bận.

Chữ ký webhook

Vì sao quan trọng. Endpoint webhook là một URL công khai nhận các yêu cầu làm thay đổi dữ liệu hồ sơ của bạn. Nếu không xác minh, bất kỳ ai tìm thấy nó cũng có thể gửi một kết quả “không có vấn đề” giả. Việc giao sự kiện cũng vốn không đáng tin cậy: máy chủ của bạn có thể khởi động lại, nên bên gửi phải gửi lại, và điều đó tạo ra sự kiện trùng lặp hoặc sai thứ tự.

Cách xác minh. Tìm cơ chế chữ ký được mô tả trong tài liệu: một khóa bí mật riêng cho từng endpoint, chữ ký trên phần thân yêu cầu thô và dấu thời gian để loại các yêu cầu cũ. Đặc tả Standard Webhooks (tiếng Anh) là một quy ước mở với các header webhook-id, webhook-timestamp và webhook-signature cùng chữ ký HMAC-SHA256, nên các thư viện sẵn có có thể xác minh nó. Hãy xem thêm cách đổi khóa bí mật, lịch gửi lại và thời điểm dừng gửi lại, ID sự kiện ổn định để loại trùng, payload mang kết quả hay chỉ mang ID, cách nhà cung cấp báo cho bạn khi việc giao thất bại (nhật ký giao, gửi lại, endpoint bị vô hiệu hóa) và sự kiện thử mà bạn có thể tự kích hoạt. Trong đợt thí điểm, hãy cho endpoint của bạn trả lỗi một lần, rồi gửi một phần thân bị sửa và một dấu thời gian đã cũ.

Tài liệu của Fileverity nêu. Webhook theo Standard Webhooks, với ba header nêu trên và chữ ký HMAC-SHA256 tính trên ID sự kiện, dấu thời gian và phần thân thô. Khóa bí mật dùng để ký chỉ hiển thị một lần và có thể đổi; tài liệu kèm mã xác minh bằng JavaScript và Python. Việc giao theo nguyên tắc ít nhất một lần và không bảo đảm thứ tự, vì vậy hãy loại trùng theo webhook-id. Lần giao thất bại được gửi lại với khoảng cách tăng dần trong vài ngày; endpoint liên tục lỗi sẽ bị vô hiệu hóa và chủ không gian làm việc nhận email; Console liệt kê các lần giao gần đây và cho phép gửi lại một lần giao. Nút Gửi thử gửi một sự kiện mẫu có ký. Sự kiện không mang kết quả: hãy lấy kết quả bằng GET /analyses/{id}. Kiểm tra văn bản là đồng bộ nên không gửi webhook, và khóa thử nghiệm không bao giờ gửi sự kiện. Xem các trang tài liệu Xác minh chữ ký và Gửi sự kiện và thử lại.

Độ tin cậy khi thử lại và khi tải cao

Idempotency và thử lại

Vì sao quan trọng. Mạng có thể đứt giữa lúc bạn gửi yêu cầu và lúc nhận phản hồi. Nếu một lần gửi lại có thể tạo lượt kiểm tra thứ hai, bạn trả tiền hai lần và có thể mở hai hồ sơ trùng. Nếu không bao giờ gửi lại, bạn bỏ sót công việc. Khóa idempotency (khóa chống xử lý trùng) cho phép nhà cung cấp nhận ra một lần gửi lại và trả về kết quả của lần đầu.

Cách xác minh. Tìm header khóa idempotency ở mọi endpoint tạo ra tài nguyên mới hoặc phát sinh phí. Đọc kỹ điều gì xảy ra khi cùng một khóa được gửi lại (cùng một phản hồi, được đánh dấu là phát lại), khi khóa được dùng lại với phần thân khác (nên bị từ chối chứ không được chấp nhận âm thầm), khi yêu cầu đầu tiên vẫn đang chạy và sau một lỗi, cũng như khóa được giữ bao lâu và áp dụng trong phạm vi nào. Header này được mô tả trong một Internet-Draft của IETF (tiếng Anh) mà vào tháng 11 năm 2026 vẫn là bản dự thảo, nên chi tiết khác nhau giữa các nhà cung cấp: hãy tự thử. Trong đợt thí điểm, hãy gửi cùng một yêu cầu hai lần và ngắt kết nối giữa chừng, rồi xác nhận chỉ có một kết quả và một lần tính phí.

Tài liệu của Fileverity nêu. Header Idempotency-Key hoạt động ở mọi endpoint POST: kiểm tra văn bản, tải tệp lên, tạo và hủy lượt kiểm tra. Một lần phát lại trả về phản hồi đã lưu cùng idempotent-replayed: true, và không có gì chạy lại hay bị tính phí lần nữa. Cùng khóa với phần thân khác trả về 409 idempotency_mismatch, còn cùng khóa khi yêu cầu đầu tiên đang chạy trả về 409 idempotency_in_progress. Phản hồi lỗi không được lưu, nên gửi lại sau một lỗi sẽ chạy lại yêu cầu. Khóa có phạm vi theo không gian làm việc, chế độ (thật hoặc thử nghiệm) và endpoint, và được giữ trong một khoảng thời gian có ghi trong tài liệu. Xem trang tài liệu Idempotency.

Lỗi và mã yêu cầu

Vì sao quan trọng. Chương trình của bạn phải quyết định lỗi nào cần gửi lại, lỗi nào cần sửa, hiển thị gì cho người dùng và chuyển gì cho bộ phận hỗ trợ của nhà cung cấp. Thông báo lỗi viết dưới dạng văn bản tự do sẽ thay đổi theo thời gian, nên đoạn mã phân tích chúng sẽ hỏng. Mã yêu cầu (request ID) giúp hai bên về sau tìm lại đúng yêu cầu đó.

Cách xác minh. Tìm lỗi có cấu trúc JSON nhất quán, với mã lỗi ổn định, máy đọc được, tách khỏi thông báo dành cho con người; một bảng liệt kê mọi mã lỗi kèm trạng thái HTTP và việc có nên gửi lại hay không; và mã yêu cầu trong header của mọi phản hồi, kể cả phản hồi thành công. Kiểm tra tài liệu có nói một lượt kiểm tra thất bại có bị tính phí hay không. Trong đợt thí điểm, hãy kích hoạt từng loại lỗi (khóa sai, tệp quá lớn, định dạng không được hỗ trợ, ID không tồn tại, số dư bằng không) và xác nhận bạn phân biệt được chúng chỉ nhờ mã lỗi.

Tài liệu của Fileverity nêu. Lỗi mang type, code, message, param và request_id, và tài liệu khuyên rẽ nhánh theo code thay vì theo thông báo. Mọi phản hồi đều có header x-request-id, và bảng mã lỗi được sinh tự động từ chính các định nghĩa của API. Tài liệu nêu lỗi nào nên gửi lại và lỗi nào cần sửa trước, và một lượt kiểm tra kết thúc bằng lỗi thì không bị tính phí. Hãy nêu mã yêu cầu khi bạn liên hệ qua hello@fileverity.com hoặc dùng trang liên hệ. Xem trang tài liệu Lỗi.

Giới hạn tốc độ

Vì sao quan trọng. Một đợt tăng đột biến, chẳng hạn nhập hồ sơ tồn đọng sau kỳ nghỉ Tết Nguyên đán, xử lý hàng loạt cuối tháng hoặc cao điểm khuyến mãi 11.11 và 12.12 của sàn thương mại điện tử, có thể chạm giới hạn. Nếu không được kiểm soát, nó biến thành lỗi, và các lần gửi lại làm tình hình tệ hơn. Giới hạn cũng cho biết nhà cung cấp muốn dịch vụ được sử dụng ra sao: dàn đều công việc và ưu tiên webhook hơn truy vấn dồn dập.

Cách xác minh. Tìm giới hạn theo khóa hoặc theo tài khoản cùng khoảng thời gian áp dụng, các header phản hồi cho biết giới hạn, số lượng còn lại và thời điểm đặt lại, và phản hồi 429 kèm header Retry-After (mã trạng thái 429 được định nghĩa trong RFC 6585, tiếng Anh). Tìm các mức trần khác, chẳng hạn số tệp tải lên đồng thời hoặc đang chờ xử lý, và cách xin giới hạn cao hơn. Nếu chế độ thử nghiệm của nhà cung cấp áp dụng cùng giới hạn, hãy chạy thử một đợt dồn dập ở đó trước.

Tài liệu của Fileverity nêu. Mỗi khóa API có một giới hạn theo phút áp dụng cho mọi endpoint, kể cả các yêu cầu trả về lỗi. Mọi phản hồi đã xác thực đều mang x-ratelimit-limit-requests, x-ratelimit-remaining-requests và x-ratelimit-reset-requests, còn 429 rate_limited mang retry-after. Một mức trần riêng cho các tệp đã tải lên chưa hết hạn trả về pending_files_limit, không kèm retry-after. Khóa thử nghiệm và khóa thật dùng chung giới hạn tốc độ, nên bạn có thể thử nghiệm cơ chế chờ rồi thử lại giãn dần (backoff) bằng khóa thử nghiệm. Muốn giới hạn cao hơn, hãy trao đổi với bộ phận kinh doanh. Xem trang tài liệu Giới hạn tốc độ và header.

Dữ liệu, bằng chứng và chi phí

Lưu giữ dữ liệu

Vì sao quan trọng. Tệp gửi đi để kiểm tra thường là dữ liệu cá nhân hoặc thông tin thương mại nhạy cảm: ảnh hiện trường và ảnh tổn thất trong hồ sơ bồi thường, ảnh căn cước công dân khi tiếp nhận khách hàng mới, sao kê, hợp đồng. Nhà cung cấp trở thành bên xử lý dữ liệu đó. Bạn cần biết dữ liệu nào được lưu, ở đâu, trong bao lâu, ai xem được và có được dùng để huấn luyện mô hình hay không.

Cách xác minh. Yêu cầu một câu trả lời cho từng nhóm dữ liệu: tệp tải lên, văn bản gửi vào, dữ liệu phái sinh, kết quả, nhật ký và bản sao lưu. “Chúng tôi xóa tệp” chưa phải là câu trả lời cho đến khi nó nêu xóa những gì, khi nào và còn lại gì. Tìm bảng lưu giữ trong tài liệu, endpoint để xóa sớm hơn, nơi xử lý và các bên xử lý thứ cấp (subprocessor), tuyên bố về việc dùng dữ liệu để huấn luyện, thỏa thuận xử lý dữ liệu và tùy chọn triển khai riêng. Trong đợt thí điểm, hãy xác nhận tệp đã biến mất sau khi lượt kiểm tra kết thúc và kết quả được lưu hết hạn đúng như tài liệu.

Tại Việt Nam, khi tệp chứa dữ liệu cá nhân, bốn nội dung pháp lý dưới đây là cơ sở cho các câu hỏi bạn cần đặt với nhà cung cấp. Hiệu lực của các văn bản dưới đây được kiểm tra ngày 4 tháng 11 năm 2026. Đây là tổng quan, không phải tư vấn pháp lý, và không đánh giá việc tuân thủ của bất kỳ nhà cung cấp nào; hãy đưa bộ phận pháp chế và bảo vệ dữ liệu vào quy trình từ sớm. Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 (gọi tắt là Luật) có hiệu lực từ ngày 1 tháng 1 năm 2026 (khoản 1 Điều 38); Nghị định 356/2025/NĐ-CP, có hiệu lực cùng ngày, làm Nghị định 13/2023/NĐ-CP hết hiệu lực (khoản 2 Điều 42).

• Hợp đồng xử lý dữ liệu. Theo điểm a khoản 2 Điều 37 của Luật, bên xử lý dữ liệu cá nhân chỉ được tiếp nhận dữ liệu sau khi có thỏa thuận, hợp đồng về xử lý dữ liệu cá nhân với bên kiểm soát. Nếu bạn là bên kiểm soát và nhà cung cấp xử lý dữ liệu thay cho bạn, hãy có thỏa thuận xử lý dữ liệu trước khi gửi tệp thật lên bằng khóa thật.
• Xử lý ngoài lãnh thổ Việt Nam. Điểm c khoản 1 Điều 20 coi việc dùng nền tảng nằm ngoài lãnh thổ Việt Nam để xử lý dữ liệu cá nhân thu thập tại Việt Nam là chuyển dữ liệu cá nhân xuyên biên giới. Theo khoản 2, bên chuyển phải lập hồ sơ đánh giá tác động chuyển dữ liệu cá nhân xuyên biên giới và gửi một bản chính cho cơ quan chuyên trách bảo vệ dữ liệu cá nhân trong 60 ngày kể từ ngày đầu tiên chuyển, trừ các trường hợp tại khoản 6. Đây là câu hỏi cho pháp chế của bạn: hãy hỏi nhà cung cấp nơi xử lý ở đâu, rồi để pháp chế xác định nghĩa vụ này có áp dụng cho bạn không.
• Dữ liệu nhạy cảm. Khoản 1 Điều 4 Nghị định 356 xếp vào dữ liệu cá nhân nhạy cảm hình ảnh thẻ căn cước, thẻ căn cước công dân, chứng minh nhân dân (điểm i) và, ở điểm k, dữ liệu về lịch sử giao dịch của tài khoản ngân hàng cùng thông tin tài chính, tín dụng, bảo hiểm của khách hàng; khoản 2 yêu cầu thiết lập quy định phân quyền giới hạn truy cập, quy trình xử lý và các biện pháp bảo mật khi xử lý loại dữ liệu này. Nếu luồng của bạn gửi loại tệp này, hãy xác định điều đó trước khi chọn tệp mẫu cho đợt thí điểm.
• Thông báo sự cố. Khoản 1 Điều 23 đặt thời hạn chậm nhất 72 giờ kể từ khi phát hiện vi phạm để thông báo cho cơ quan chuyên trách bảo vệ dữ liệu cá nhân, khi vi phạm có thể gây tổn hại đến quốc phòng, an ninh quốc gia, trật tự, an toàn xã hội hoặc xâm phạm tính mạng, sức khỏe, danh dự, nhân phẩm, tài sản của chủ thể dữ liệu; bên xử lý phát hiện vi phạm phải thông báo kịp thời cho bên kiểm soát. Hãy hỏi nhà cung cấp họ báo cho bạn bằng kênh nào và trong bao lâu.

Văn bản pháp luật: Luật Bảo vệ dữ liệu cá nhân 91/2025/QH15, Công báo và Nghị định 356/2025/NĐ-CP, Công báo.

Tài liệu của Fileverity nêu. Bảng lưu giữ trong Lưu giữ dữ liệu và bảo mật đề cập đến từng nhóm dữ liệu. Tệp tải lên bị xóa khi một lượt kiểm tra bắt đầu và trong mọi trường hợp đều bị xóa sau một khoảng thời gian được nêu; DELETE /files/{id} xóa sớm hơn. Văn bản gửi vào được đánh giá rồi loại bỏ, không bao giờ được lưu. Kết quả kiểm tra được giữ trong một khoảng thời gian có giới hạn, còn kết quả văn bản được giữ mà không kèm văn bản. Bằng chứng theo từng trang của tài liệu được giữ trong thời gian ngắn hơn kết quả, vì vậy hãy tải báo cáo PDF ngay khi lượt kiểm tra kết thúc nếu bạn cần lưu bằng chứng này. Nhật ký yêu cầu không ghi phần thân của yêu cầu hay phản hồi. Phân tích ảnh và tài liệu chạy trên máy chủ do Entogo vận hành tại Toronto, Canada, còn ứng dụng web chạy tại Hoa Kỳ; cả hai đều nằm ngoài Việt Nam. Danh sách bên xử lý thứ cấp nằm ở trang Tin cậy và bảo mật, điều khoản xử lý dữ liệu nằm trong thỏa thuận xử lý dữ liệu, và triển khai riêng được cung cấp cho khách hàng Enterprise theo yêu cầu. Hãy đối chiếu thỏa thuận với các yêu cầu nêu trên cùng pháp chế của bạn.

Bằng chứng kiểm toán và phiên bản mô hình

Vì sao quan trọng. Khi một hồ sơ bị gắn cờ bị khiếu nại nhiều tháng sau, bạn phải chứng minh được điều gì đã được kiểm tra, khi nào, bằng mô hình nào và phiên bản nào, và tệp không đổi kể từ đó. Một điểm số đơn lẻ trong cơ sở dữ liệu của bạn không làm được điều đó. Nếu nhà cung cấp đổi mô hình mà không báo, kết quả trên cùng một tệp có thể thay đổi, và bạn không thể so sánh kết quả của đợt thí điểm với môi trường sản xuất hay giải thích sự khác biệt giữa hai lượt kiểm tra.

Cách xác minh. Tìm một ID ổn định cho mỗi kết quả để bạn lưu cùng hồ sơ; giá trị băm của tệp đã kiểm tra; dấu thời gian tin cậy từ một tổ chức cấp dấu thời gian, theo RFC 3161 (tiếng Anh), để thời điểm không chỉ dựa vào đồng hồ của nhà cung cấp; một báo cáo tải xuống được; và cách để bên thứ ba xác nhận mà không cần tài khoản. Kiểm tra mỗi kết quả có nêu chính xác phiên bản mô hình không, bạn có ghim được một yêu cầu vào một phiên bản không và phiên bản đó còn khả dụng bao lâu, cùng cách thông báo thay đổi và ngừng cung cấp. Hướng dẫn về SHA-256 và dấu thời gian tin cậy giải thích giá trị băm và dấu thời gian mỗi thứ chứng minh điều gì.

Nếu bằng chứng này có thể phải dùng trong một tranh chấp tại Việt Nam, hãy tách hai việc: dấu thời gian RFC 3161 là bằng chứng kỹ thuật về thời điểm tồn tại của tệp, còn giá trị chứng cứ là một câu hỏi pháp lý. Theo khoản 2 Điều 11 Luật Giao dịch điện tử số 20/2023/QH15, giá trị chứng cứ của thông điệp dữ liệu được xác định căn cứ vào độ tin cậy của cách thức khởi tạo, gửi, nhận hoặc lưu trữ, cách thức bảo đảm và duy trì tính toàn vẹn, cách thức xác định người khởi tạo và các yếu tố phù hợp khác. Dịch vụ cấp dấu thời gian là một dịch vụ tin cậy (điểm a khoản 1 Điều 28); dịch vụ tin cậy là ngành, nghề đầu tư kinh doanh có điều kiện (khoản 2), nên tổ chức cung cấp phải có giấy phép (khoản 3). Một trong các điều kiện là doanh nghiệp được thành lập và hoạt động hợp pháp trên lãnh thổ Việt Nam (điểm a khoản 1 Điều 29). Vì vậy đừng mặc định rằng dấu thời gian do một tổ chức nước ngoài cấp có giá trị như dịch vụ được cấp phép tại Việt Nam; hãy nhờ luật sư của bạn đánh giá. Các điều trên được đối chiếu ngày 4 tháng 11 năm 2026. Nguồn: Luật Giao dịch điện tử số 20/2023/QH15, văn bản hợp nhất năm 2026 của Văn phòng Quốc hội.

Tài liệu của Fileverity nêu. Báo cáo ảnh và tài liệu mang mã báo cáo, giá trị băm SHA-256 của tệp đã kiểm tra, dấu thời gian RFC 3161 và một trang xác minh công khai mà bất kỳ ai có liên kết đều dùng được mà không cần tài khoản, cùng một PDF được niêm phong. Mỗi kết quả nêu snapshot đã tạo ra nó; một ID mô hình như fvimg-2 trỏ tới một snapshot có ngày, và truyền một ID snapshot vào model sẽ ghim yêu cầu vào snapshot đó. Các thay đổi trong v1 chỉ mang tính bổ sung và được liệt kê trong changelog, nên ứng dụng khách cần bỏ qua các trường mà nó không nhận ra. Kết quả văn bản mang ID phát hiện và snapshot đã tạo ra chúng. Thời hạn báo trước khi ngừng cung cấp một snapshot cần được ghi trong thỏa thuận của bạn, vì vậy hãy yêu cầu nhà cung cấp nêu bằng văn bản. Xem các trang tài liệu Đối tượng báo cáo, Quy ước và Nhật ký thay đổi.

Tính phí và chế độ thử nghiệm

Vì sao quan trọng. Bảng giá thường che giấu những quy tắc quyết định hóa đơn: đơn vị tính phí, việc có tính phí lượt kiểm tra thất bại, bị hủy hay được gửi lại không, cách làm tròn và một tác vụ chạy ngoài tầm kiểm soát có thể tốn bao nhiêu. Bạn cũng cần xây dựng và thử tích hợp mà không tốn tiền hay làm nhiễu dữ liệu sản xuất. Khi nhà cung cấp niêm yết giá bằng ngoại tệ và có trụ sở ở nước ngoài, hãy hỏi kế toán của bạn trước khi nạp số dư về loại chứng từ sẽ nhận được và cách ghi nhận khoản chi.

Cách xác minh. Tìm đơn vị tính phí của từng loại tác vụ (theo ảnh, theo tài liệu, theo khối ký tự) và quy tắc làm tròn. Kiểm tra yêu cầu thất bại, bị hủy và bị từ chối có bị tính phí không, mô hình tính phí là trả trước hay đăng ký, có hạn mức chi tiêu, cảnh báo số dư thấp và báo cáo sử dụng để bạn đối chiếu với số liệu của chính bạn không. Một chế độ thử nghiệm tốt không bao giờ tính phí, áp dụng cùng quy tắc kiểm tra tính hợp lệ của yêu cầu và nói chính xác nó mô phỏng gì, không mô phỏng gì: thời gian xử lý, webhook và kết quả thật thường là những điểm còn thiếu. Trong đợt thí điểm, hãy đối chiếu báo cáo sử dụng của nhà cung cấp với nhật ký của bạn, kể cả một lần thất bại có chủ ý.

Tài liệu của Fileverity nêu. API tính phí trả trước, trừ vào số dư của không gian làm việc, không có gói đăng ký. Giá tính theo mỗi lượt kiểm tra ảnh, mỗi lượt kiểm tra tài liệu và mỗi khối ký tự văn bản, làm tròn lên theo từng yêu cầu, tính bằng đô la Mỹ và chưa gồm thuế; thuế áp dụng, nếu có, được tính lúc thanh toán. Mỗi lần nạp tiền có một hóa đơn trong Console, và khách hàng doanh nghiệp có thể thêm mã số thuế khi thanh toán. Với kiểm tra ảnh và tài liệu, khoản phí được tạm giữ khi tạo lượt kiểm tra và được hoàn lại nếu lượt kiểm tra thất bại hoặc bị hủy; yêu cầu bị từ chối trước khi đánh giá thì không bị tính phí. Lượt dùng thử miễn phí ban đầu được trừ trước số dư. Mỗi khóa có thể có hạn mức chi tiêu hằng tháng, cảnh báo số dư thấp gửi qua email và webhook balance.low, và mỗi lượt kiểm tra báo khoản phí của nó trong usage. Khóa thử nghiệm không bao giờ tính phí hay dùng lượt dùng thử miễn phí, trả về ngay một mẫu cố định, áp dụng cùng quy tắc kiểm tra tính hợp lệ, giới hạn tốc độ và mã lỗi, và không gửi webhook nào ngoài sự kiện thử của Console. Mã báo cáo mẫu bắt đầu bằng FV-TEST- và không có trang xác minh công khai. Giá hiện hành nằm ở Giá và thanh toán và trang API; cách khóa thử nghiệm hoạt động nằm ở Xác thực và khóa API.

Câu hỏi thường gặp

Nên chọn API đồng bộ hay bất đồng bộ?

Không cách nào tốt hơn hẳn cách còn lại. Đầu vào ngắn như văn bản thuần hợp với lệnh gọi đồng bộ, còn tệp cần phân tích nặng hơn thường trả về một trạng thái trước. Điều quan trọng là tài liệu định nghĩa rõ vòng đời, hỗ trợ cả chờ, truy vấn định kỳ lẫn webhook, và chương trình của bạn xử lý được trạng thái đang chờ.

Tôi cần webhook, hay chỉ cần truy vấn định kỳ?

Truy vấn định kỳ là đủ cho bản thử nghiệm ban đầu hoặc khối lượng thấp. Webhook tiết kiệm số yêu cầu và hạn mức tốc độ, nên hợp với môi trường sản xuất. Dù chọn cách nào, hãy xác minh chữ ký, xử lý sự kiện trùng lặp và trạng thái đang chờ.

Khóa idempotency có phải là một chuẩn không?

Đó là một quy ước phổ biến, và một Internet-Draft của IETF mô tả nó nhưng đến tháng 11 năm 2026 vẫn chưa trở thành RFC. Hãy coi hành vi chính xác là đặc thù của từng nhà cung cấp và thử nó. Hành vi của Fileverity được ghi ở trang Idempotency.

API tốt có nghĩa là bộ phát hiện chính xác không?

Không. Các điểm kiểm tra này chỉ nói về phần tích hợp, không nói về chất lượng phát hiện. Hãy đánh giá khả năng phát hiện trên tệp của chính bạn, với nhãn mà bạn tin cậy, theo hướng dẫn về độ chính xác và hướng dẫn chọn phần mềm.

API phát hiện AI có hỗ trợ tiếng Việt không?

Hãy hỏi riêng cho từng tác vụ, vì câu trả lời có thể khác nhau giữa ảnh, tài liệu và văn bản thuần. Với Fileverity, kiểm tra văn bản thuần chấp nhận tiếng Anh, tiếng Pháp, tiếng Đức, tiếng Tây Ban Nha và tiếng Trung, không áp dụng cho tiếng Việt; phần giải thích các phát hiện về tài liệu cũng chỉ có năm ngôn ngữ đó. Hãy thử bằng các tệp thật của bạn trước khi quyết định.

Gửi tệp chứa dữ liệu cá nhân của khách hàng đến API đặt ngoài Việt Nam có được không?

Không có câu trả lời chung; đó là một câu hỏi pháp lý của riêng bạn. Điều 20 của Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 coi việc dùng nền tảng ngoài lãnh thổ Việt Nam để xử lý dữ liệu cá nhân thu thập tại Việt Nam là chuyển dữ liệu cá nhân xuyên biên giới, và yêu cầu bên chuyển lập hồ sơ đánh giá tác động rồi gửi cho cơ quan chuyên trách trong 60 ngày kể từ lần chuyển đầu tiên, trừ các trường hợp được loại trừ. Ngân hàng, công ty bảo hiểm và cơ quan nhà nước còn có thể chịu quy định riêng của ngành. Hãy để pháp chế của bạn quyết định; trong lúc chờ, bạn có thể bắt đầu đợt thí điểm bằng tệp mẫu không chứa dữ liệu cá nhân.

Tôi có thể dùng thử API Fileverity mà không phải trả tiền không?

Có. Không gian làm việc đầu tiên của bạn có lượt dùng thử miễn phí ban đầu, và khóa thử nghiệm không bao giờ tính phí. Hãy làm theo Bắt đầu nhanh và xem Giá và thanh toán để biết điều kiện.

Danh sách kiểm tra cho đợt thí điểm

Hãy chia đợt thí điểm thành ba vòng và ghi lại mọi câu trả lời kèm ngày tháng. Vòng đầu là rà soát tài liệu của nhà cung cấp: trả lời cả mười điểm kiểm tra từ tài liệu của từng phương án và loại các trường hợp rõ ràng không phù hợp trước khi viết mã. Vòng hai dùng khóa thử nghiệm: xây tích hợp với chế độ thử nghiệm. Vòng ba dùng khóa thật: dùng một khóa thật có hạn mức chi tiêu thấp và một mẫu tệp mà bạn được phép gửi. Về cách lấy mẫu, gắn nhãn và chấm điểm chất lượng phát hiện, hãy theo thiết kế đợt thí điểm trong Cách chọn phần mềm phát hiện ảnh AI.

Hãy giữ các câu trả lời cạnh ma trận đáp ứng và cách chấm điểm trong hướng dẫn chọn phần mềm. Để bắt đầu với Fileverity, hãy đọc trang API, các trang API phát hiện ảnh AI và API phát hiện giả mạo tài liệu, cùng Bắt đầu nhanh.

Tác giả Yang Zheng · Người kiểm duyệt Bill Liu