Plan capacity, not people
When I worked on capacity planning for bank operations and service teams, most useful questions concerned workload, roles and available capacity. We did not need an assessment of each employee to discuss whether a team could handle the work ahead. That is where I start with workforce AI. The question should justify the data collected, especially when a planning request could drift into judgments about individual performance.
Define the decision first. A team-capacity discussion needs aggregate availability and workload. An individual employment decision carries different requirements and consequences, and it does not belong in a general planning pilot.
Choose a bounded workflow, such as spotting a mismatch between planned project demand and approved team capacity. State which information is used and which decisions are out of scope. Do not let a planning assistant quietly become an evaluator of individual performance or suitability.
Bring HR, privacy and the business in before engineering
In every Claude rollout I advise, identity, permissions and data boundaries come first, ahead of prompts or use cases. Workforce planning is where that discipline matters most. HR, business and privacy owners decide what data and process are appropriate for their organization. Technical ability to retrieve a field does not make a new use of it appropriate, so document the purpose explicitly.
Obligations also vary by organization and jurisdiction. A healthcare provider, a life sciences company and a bank each operate under different rules, and the right answer for one is not automatically right for another. That determination belongs to the organization's own privacy and legal specialists, and the pilot design should record their conclusions rather than assume them.
Write the approved purpose, the allowed fields and the excluded decisions on a single page, and have HR, privacy and the business sponsor sign it. That page becomes the reference for every later request to expand scope. Without it, each new question gets negotiated from scratch, and the boundary erodes one reasonable-sounding exception at a time until nobody can say what the assistant was approved to do.
Minimize the fields, then minimize again
List the fields required for the selected question and drop the rest. Names, contact details and sensitive attributes are usually unnecessary for aggregate planning. Use team or role-level data wherever it meets the need.
Watch for small groups. An aggregate can still identify a person when only one employee holds a particular role in a location. Define grouping and disclosure rules for the real workforce, not a hypothetical one.
Separate approved data from speculation. An assistant should never infer health, personal circumstances or motivation from attendance patterns or free-text notes. If a question needs information that is unavailable or inappropriate, the system should say so rather than invent an explanation.
Keep interpretation bounded and humans accountable
Capacity figures rest on assumptions about availability, allocation and demand. Make them visible. A project forecast is not a confirmed assignment, and the response should distinguish planned from committed work and state the period covered.
Test with sanitized cases: missing assignments, overlapping allocations, reorganized teams. An apparent over-allocation may be a stale record rather than a staffing problem, and the evaluation should reward the assistant for naming that uncertainty.
A planning summary can inform a manager's conversation. It is never an automatic instruction about an individual employee. Establish review and escalation paths that match the organization's policies and the significance of the decision.
Evaluate the whole information boundary
Test permitted aggregate questions and requests for inappropriate detail. Check responses, exports and operational logs; a clean interface means little if sensitive inputs land in unrestricted troubleshooting records. Then try producing the same useful answer with fewer fields or broader groups. If extra personal detail does not materially improve the decision, leave it out of the workflow and its logs.
Watch how users push on the scope. Repeated requests for individual judgments signal that the boundary or interface needs work, and training alone will not fix it. Reassess the approved purpose whenever the audience grows, because information suitable for a small planning group may need broader aggregation for a wider management population.
A successful pilot improves visibility of approved capacity and demand assumptions. It does not by itself establish fairness, legal compliance or suitability for employment decisions, and leaders should say so plainly when they report results to the board.