A practical review framework for evaluating the boundaries around AI-assisted construction work. A formal starting point for reviewing the perimeter around AI-assisted work.
AI that participates in operational work deserves the same scrutiny as any other party with access to your systems and records. This page organizes the review materials your IT, security, legal, and operations teams may wish to request and confirm for a proposed Briq deployment.
It is a practical agenda—not an attestation, certification, or contractual commitment. The applicable product configuration and signed agreement remain the source for what is provided in a specific engagement.
A workflow may organize inputs and prepare the next operational step.
Outputs can be checked against the source material and exceptions surfaced.
Your team confirms which actions require a human decision before they proceed.
Important distinction: human approval is not assumed by this diagram. It is a workflow control to review and configure according to the action, system of record, and your organization’s policy.
Use these topics to structure due diligence and to identify the documentation, configuration detail, and contractual terms your team needs to evaluate.
Why it matters. Construction records, estimates, schedules, and financial data require a clear account of where they are processed and how boundaries between customers are maintained.
Review request. Request the current data residency options, geographic processing locations, and a written explanation of tenant isolation architecture.
Why it matters. Protection needs to be understood across the full lifecycle of information, including transfer, storage, operational access, and key handling.
Review request. Request the exact encryption standards used at rest and in transit, key management practices, ownership model, rotation procedures, and any implementation-specific limitations.
Why it matters. When workflows use external model providers, teams need to understand what content may be sent, how it is handled, and what commitments govern reuse or retention.
Review request. Request the current third-party model inventory, data-flow description, and applicable provider agreements. Confirm in writing whether zero-retention terms and a non-training guarantee apply to your configuration, and identify any exceptions.
Why it matters. Identity is a control plane. IT teams need to evaluate how workforce identities are established, administered, and removed as people and projects change.
Review request. Request supported authentication and federation options, including whether SAML-based SSO is available for your deployment, identity-provider compatibility, account lifecycle behavior, and configuration prerequisites.
Why it matters. Access should align with the responsibilities of each user and with the source systems a workflow is permitted to reach.
Review request. Request the role model, permission boundaries, administrative controls, and evidence of how worker access is scoped in the proposed deployment. Confirm whether a digital worker’s access is limited to the permissions of its assigned human user.
Why it matters. Teams need a usable record of what occurred: the request, the systems involved, the work performed, and the decision points surrounding it.
Review request. Request available audit records, prompt and action coverage, system-access records, retention behavior, and export options. Confirm whether records are immutable and whether agent actions are described in plain language that supports an operational investigation.
Why it matters. Automation and authority are separate decisions. A workflow can prepare, verify, or recommend work while an organization retains control over consequential actions.
Review request. Request a workflow-by-workflow approval map that identifies what may proceed automatically, what requires a human decision, and how those gates are configured.
Why it matters. Project data has a lifecycle. Governance should account for operational need, customer policy, legal obligations, and the end of a workspace or engagement.
Review request. Request retention schedules, deletion procedures, backup considerations, customer responsibilities, and the evidence available when deletion is requested. Confirm whether certified deletion is available and what data and systems it covers.
Why it matters. A meaningful review extends beyond the primary provider to the organizations that may support delivery, infrastructure, support, or model capability.
Review request. Request the current subprocessor list, each party’s role, the process and notification terms for changes, and the documentation available for downstream providers.
Why it matters. The relevant question is not whether incidents can occur; it is whether responsibilities, investigation paths, communications, and remediation expectations are understood in advance.
Review request. Request the incident response plan, customer communication procedure, escalation contacts, and the breach notification service-level commitments that would apply to your agreement. Confirm timelines, triggering conditions, and customer responsibilities in writing.
Why it matters. Operational continuity requires a deliberate plan for retrieving information and completing a transition if the relationship or a particular workflow ends.
Review request. Request available export formats, API or retrieval options, offboarding steps, timing assumptions, and the respective responsibilities of Briq and your team.
Request the current security review materials and discuss the controls, documentation, and configuration questions that matter to your organization.
Request a security review