How I would build and mature KPFF's AI program.

Prepared for the KPFF Consulting Engineers team

The posting describes a firm where AI work is already happening across offices and Reporting Centers, and a role meant to bring structure and momentum to it — a practical front door, coordinated governance, records that hold up, pilots that reach a decision, and reporting leadership can act on.

This is my proposal for how I would do that. It is built from the public posting and uses fictional example data throughout. It assumes nothing about how KPFF works today; the first ninety days are for finding that out.

A short operating proposal, readable in about five minutes, with two worked examples behind it. Not a description of KPFF's environment, and not a claim to know what is already in place.

Every request takes the same seven stages. Triage is the only place they diverge, and what it decides is how much review the rest of the route carries.

Set at triage, applied from Review on

How a request gets classified, and why

Five things the posting makes clear, what each one would change about how I work, and — for three of them — the record it produces.

1. RR-01

   In a decentralized firm, the front door has to be easier than the workaround.

   Intake stays short enough to complete between meetings, with published timelines so people know what to expect. Requests come back the same day with specific questions, never a bare rejection. Nothing here can be mandated, so the process has to be worth using — if people route around it, the process is the defect, not the people.

   The posting is explicit that KPFF is decentralized and that success depends on relationships and influence rather than formal authority.

2. RR-02

   The work started before the program did.

   The lifecycle starts at Discover, not Intake. The first inventory covers what already exists — tools in use, informal practices, pilots nobody registered, the people who have quietly become the local expert. A program that behaves as though the work began the day it arrived loses the people already doing it, and those are exactly the people it needs.

   The role is described as bringing structure and momentum to AI efforts already underway across the firm.

3. RR-03

   Coordination with real accountability, and no approval authority.

   I would operate underneath existing policy, not author it. My responsibility matrix has no approval mark in the program manager column — every decision record names the owner who made it. What I am accountable for is that the right people saw the right material in time, that the decision got written down with its reasoning, and that the conditions attached to it are tracked to closure. Exhibit B is one of those records.

   The role reports to the Director of Technology and escalates policy, risk, budget, security, legal, vendor, and strategic decisions to the appropriate functional owner or governance body. AI policy and the Six Prescriptions are already in place.

   Exhibit BDecision log

   DEC-2026-04AI Governance Committee

   Automated resume screening and candidate ranking

   2026-05-18

   Decision owner

   Grace Lin, People & Culture Director, with Risk, Legal & Privacy concurrence

   What was decided

   Not approved as proposed. Automated screening, scoring, ranking, and shortlist generation are declined for the current recruiting cycle.

   The vendor could not produce adverse-impact testing documentation, and the firm has no internal capability to validate the model's effect on protected groups. Without that, a ranked shortlist would shape employment outcomes on reasoning nobody in the firm can explain.

   What was rejected, and why

   • Approve with human review of the ranked list — rejected; reviewing a ranking still inherits the ranking
   • Approve for a single office as a test — rejected; the harm and the evidence gap do not shrink with scope
   • Defer entirely — rejected in favor of separating the logistics problem, which is real and solvable

   Conditions

   • Reconsideration requires vendor adverse-impact documentation and a defined validation approach
   • People & Culture owns any future reconsideration, not the program

   Linked records

   UC-004 TL-04

   Review on

   2027-02-01

4. RR-04

   Review effort matched to risk, published so anyone can see why.

   Three pathways rather than one queue. A meeting summary should never wait behind a recruiting workflow, and a recruiting workflow should never move at the speed of a meeting summary. The triage questions are published, and every classification shows which answers put it there — so a requester who disagrees has something specific to argue with. Exhibit A shows a classification and the answers behind it.

   The posting names the higher-risk categories that need coordinated review: HR and recruiting, public-facing content, sensitive data, business-system actions, and autonomous or semi-autonomous agents.

   Exhibit ATriage result

   UC-004Use-case register

   Early-career recruiting screening and interview support

   People & Culture · submitted 2026-03-04

   Classification

   Elevated reviewFour to six weeks, longer if the evidence a reviewer needs does not exist yet

   Answers that decided it

   • R-01Yes — affects decisions about individualsraises to elevated review
   • R-02Yes — restricted data classificationraises to elevated review
   • R-07Yes — new or unreviewed toolraises to structured review

   Not recorded

   A score. There is no arithmetic here to disagree with. Run it yourself.

5. RR-05

   Records and reporting that hold up when someone asks later.

   One register that every other view derives from, so a leadership number cannot contradict the underlying record. Decision entries capture what was rejected and why — the field that makes a program defensible a year later. Every reported figure carries an evidence label, because leadership can only act on a number when they know how good it is. Exhibit C is one that did not clear its threshold.

   The posting calls for an inventory, use-case register, decision log, exception log, and AI-use records sufficient for a defensible audit trail, plus leadership reporting on adoption, risks, decisions, and outcomes.

   Exhibit CPilot measurement

   PIL-003Pilot register

   Standards knowledge search

   2026-04-13 — 2026-09-15

   Citation accuracy on the 100-question test set

   Evidence: measured

   threshold to scale 95%

   measured 91%

   Measuring against the scale threshold. Accuracy 91% against a 95% target; the library cleanup that would close the gap is scheduled.

   Also measured

   • Median time to locate a current standard1.8 minutes against Under 2 minutes, from a 6.5-minute baseline · measured
   • Weekly active users among pilot participants41 of 60 against 60% of 60 licensed users · measured

   What the gap is

   The accuracy gap is mostly a records problem. Eight of the nine failing questions cite documents that should have been retired years ago.

   Decision available

   Scale, extend the measurement window, or hold pending library cleanup

Listen before organizing, organize before piloting. The sequence matters more than the contents — a program that arrives with a framework instead of questions spends the rest of the year recovering from it.

• Start with the business problem, not the tool.

  A request that cannot name the problem is not ready for review, and saying so early saves everyone a cycle.

• Match the review to the risk.

  Most requests should take the short path. The pathway model only pays off if the short path is genuinely short.

• Name the owner before anything starts.

  If nobody will own the outcome, the pilot does not begin.

• Keep people accountable for consequential output.

  Oversight means a named role, a specific check, a defined frequency, and the authority to override. Anything less is a claim, not a control.

• Write down the reasoning, not just the decision.

  Including the options that were considered and rejected.

• Measure honestly, including when the answer is smaller than hoped.

  Baselines before the tool arrives, thresholds set before results are known, and self-reported benefits labeled as such.

Everything above is a starting proposal. The structure is what I would bring on day one; the specifics should change once I know how KPFF actually operates. These are the questions I would be asking in week one — and a few of them are questions I would want to ask in an interview.

• What AI work is underway right now, formally and informally, and who is doing it?
• Who genuinely decides today on security exceptions, vendor contracts, client data handling, and changes to employment processes?
• What do client agreements say about processing project material in third-party services, and how much does it vary?
• What has already been tried that did not work, and why do people believe it failed?
• How do offices outside the largest ones actually get information, and what feels decided without them?
• What does leadership see today, and which of it do they act on?